reassign 388399 tex-common
severity 388399 normal
retitle 388399 document that packages need to clean up their font cache
stop
Steve Langasek [EMAIL PROTECTED] wrote:
That's actually a good idea, yes. Package maintainers have to set
TEXMFVAR so something inside the current directory. Is the
Hi Ryan,
Steve Langasek [EMAIL PROTECTED] wrote:
On Sat, Sep 30, 2006 at 11:31:14AM +0200, Frank Küster wrote:
But if the package build requires access to $HOME/.texmf-var, that's still
a
bug that should be fixed;
No it doesn't require that. Only if there is a $HOME directory, and it
On Sat, Sep 30, 2006 at 11:31:14AM +0200, Frank Küster wrote:
But if the package build requires access to $HOME/.texmf-var, that's still a
bug that should be fixed;
No it doesn't require that. Only if there is a $HOME directory, and it
is writable, then it is used. Otherwise
[Frank, you seem to have a wrong mail alias for me somewhere;
[EMAIL PROTECTED] is no longer in use, but that's where your cc: was
sent.]
On Wed, Oct 04, 2006 at 09:32:16AM +0200, Frank Küster wrote:
However, he also agrees with me that every package affected by this bug is
violating policy
Ralf Stubner [EMAIL PROTECTED] wrote:
On Sun, Oct 01, 2006 at 21:13 +0200, Frank Küster wrote:
I didn't check the mktexnam code - but I'm a little surprised here. I
wasn't aware of the test for SYSTEXMF, but in case the test fails,
i.e. the input is from a private TEXMF tree, shouldn't the
On Mon, Oct 02, 2006 at 08:07 +0200, Frank Küster wrote:
Okay, you are right, indeed this check is already done. So we could
gain some additional security by making sure that the SYSTEXMF variable
is not set in the user environment, but only read from the system-wide
texmf.cnf.
That's
---BeginMessage---
Ralf Stubner wrote:
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
Frank Küster wrote:
Thiemo Seufer [EMAIL PROTECTED] wrote:
So, if I understand that correctly, the bug was fixed by running mktexmf
as non-root, and the change of the cache location
Steve Langasek [EMAIL PROTECTED] wrote:
The old solution was a security problem because the directories were
world-writable -- /var/mail is not, the directory is only writable by the
'mail' group -- which almost certainly makes symlink attacks possible,
looking at the source of mktexmf, as
---BeginMessage---
On Sat, Sep 30, 2006 at 11:56:30PM +0100, Thiemo Seufer wrote:
I meant the the earlier security bug you mentioned. To me, the solution
for the earlier bug as well as the current one looks like keeping the
font cache in /var but maintaining it via a mktexmf user.
The
[please note the different bug number]
Steve Langasek [EMAIL PROTECTED] wrote:
Where does the input for the cache come from? If the input is always from a
privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
-- and, I think, vastly preferable -- to have an suid wrapper
On Sun, Oct 01, 2006 at 14:48 +0200, Frank Küster wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
Where does the input for the cache come from? If the input is always from a
privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
-- and, I think, vastly preferable -- to
Ralf Stubner [EMAIL PROTECTED] wrote:
On Sun, Oct 01, 2006 at 14:48 +0200, Frank Küster wrote:
The input can come from the current directory, the user's own TEXMF tree
or any directory specified in the MFINPUTS (etc.) variable.
The output goes to the user's own TEXMF tree, though. If the
On Sun, Oct 01, 2006 at 21:13 +0200, Frank Küster wrote:
I didn't check the mktexnam code - but I'm a little surprised here. I
wasn't aware of the test for SYSTEXMF, but in case the test fails,
i.e. the input is from a private TEXMF tree, shouldn't the output go to
TEXMFVAR
On Fri, Sep 29, 2006 at 01:35:14PM +0200, Frank Küster wrote:
On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:
I'm resending this mail, and include the porters list with hope for some
help. We really won't be able to debug this problem without contact to
someone who has at
[Summary for the buildd people: We still need your help]
Steve Langasek [EMAIL PROTECTED] wrote:
But if the package build requires access to $HOME/.texmf-var, that's still a
bug that should be fixed;
No it doesn't require that. Only if there is a $HOME directory, and it
is writable, then it
Frank Küster wrote:
[Summary for the buildd people: We still need your help]
Steve Langasek [EMAIL PROTECTED] wrote:
But if the package build requires access to $HOME/.texmf-var, that's still a
bug that should be fixed;
No it doesn't require that. Only if there is a $HOME directory,
clone 388399 -1
retitle -1 Font cache, when in /tmp, should use per-user directories
severity -1 important
submitter -1 Steve Langasek [EMAIL PROTECTED]
stop
Frank Küster [EMAIL PROTECTED] wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
So somewhere, there is a very, very wrong assumption that
Frank Küster wrote:
[Summary for the buildd people: We still need your input]
Thiemo Seufer [EMAIL PROTECTED] wrote:
sudo mkdir -p /tmp/texfonts/source/jknappen/ec
sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
make -C docs/psdoc
So somewhere, there is a very, very wrong
[Summary for the buildd people: We still need your input]
Thiemo Seufer [EMAIL PROTECTED] wrote:
sudo mkdir -p /tmp/texfonts/source/jknappen/ec
sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
make -C docs/psdoc
So somewhere, there is a very, very wrong assumption that it's ok to use a
[now in the new bug about the fontcache in /tmp]
Thiemo Seufer [EMAIL PROTECTED] wrote:
If the admin chooses to create an empty /tmp/texfonts hierarchy without
write access for users that need the font cache, that's equivalent to
him creating an empty /var/cache/fonts/... without users having
---BeginMessage---
Frank Küster wrote:
[Summary for the buildd people: We still need your input]
Thiemo Seufer [EMAIL PROTECTED] wrote:
sudo mkdir -p /tmp/texfonts/source/jknappen/ec
sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
make -C docs/psdoc
So somewhere, there is a
---BeginMessage---
[Summary for the buildd people: We still need your input]
Thiemo Seufer [EMAIL PROTECTED] wrote:
sudo mkdir -p /tmp/texfonts/source/jknappen/ec
sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
make -C docs/psdoc
So somewhere, there is a very, very wrong assumption that
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
Frank Küster wrote:
Thiemo Seufer [EMAIL PROTECTED] wrote:
So, if I understand that correctly, the bug was fixed by running mktexmf
as non-root, and the change of the cache location is only a collateral.
No, or I do not
---BeginMessage---
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
Frank Küster wrote:
Thiemo Seufer [EMAIL PROTECTED] wrote:
So, if I understand that correctly, the bug was fixed by running mktexmf
as non-root, and the change of the cache location is only a collateral.
Thiemo Seufer [EMAIL PROTECTED] wrote:
No, or I do not understand what you mean.
I meant the the earlier security bug you mentioned. To me, the solution
for the earlier bug as well as the current one looks like keeping the
font cache in /var but maintaining it via a mktexmf user.
That would
Ralf Stubner wrote:
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
Frank Küster wrote:
Thiemo Seufer [EMAIL PROTECTED] wrote:
So, if I understand that correctly, the bug was fixed by running mktexmf
as non-root, and the change of the cache location is only a
On Sat, Sep 30, 2006 at 08:19:22PM +0200, Ralf Stubner wrote:
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
Frank Küster wrote:
Thiemo Seufer [EMAIL PROTECTED] wrote:
So, if I understand that correctly, the bug was fixed by running mktexmf
as non-root, and the change of
On Sat, Sep 30, 2006 at 11:56:30PM +0100, Thiemo Seufer wrote:
I meant the the earlier security bug you mentioned. To me, the solution
for the earlier bug as well as the current one looks like keeping the
font cache in /var but maintaining it via a mktexmf user.
The problem is that
On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:
I'm resending this mail, and include the porters list with hope for some
help. We really won't be able to debug this problem without contact to
someone who has at least read access to the affected buildds.
You can debug it by
Steve Langasek [EMAIL PROTECTED] wrote:
On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:
I'm resending this mail, and include the porters list with hope for some
help. We really won't be able to debug this problem without contact to
someone who has at least read access to the
Frank Küster wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:
I'm resending this mail, and include the porters list with hope for some
help. We really won't be able to debug this problem without contact to
someone who has at
Hi,
despite all tips, this is still a plea to the people with access to the
buildds.
Thiemo Seufer [EMAIL PROTECTED] wrote:
It looks like the build creates font files with root permissions, and
can't alter them lateron when running without elevated privileges.
So any environment with real
Frank Küster [EMAIL PROTECTED] wrote:
Dear Buildd admins,
there seems to be a problem with packages that build-depend on tetex,
which only manifests on the alpha, mips and mipsel buildds. We need
your help to investigate this, please see below.
Nobody has answered quickly, but I found
Dear Buildd admins,
there seems to be a problem with packages that build-depend on tetex,
which only manifests on the alpha, mips and mipsel buildds. We need
your help to investigate this, please see below.
Ralf Stubner [EMAIL PROTECTED] wrote:
The strange thing is that mktexmf, which is
34 matches
Mail list logo
