app-text/cstetex-2.0.2-r1: vulnerable via glsa(200603-02) ( ver-rev < 2.0.2-r2 ), affects ('amd64', 'x86') app-text/pstotext-1.8g: vulnerable via glsa(200507-29) ( ver-rev < 1.8g-r1 ), affects ('amd64', 'ppc', 'ppc64', 'sparc', 'x86') app-text/ptex-3.1.4-r2: vulnerable via glsa(200603-02) ( ver-rev < 3.1.5-r1 ), affects ('alpha', 'amd64', 'ppc', 'ppc-macos', 'ppc64', 'sparc', 'x86') app-text/ptex-3.1.5: vulnerable via glsa(200603-02) ( ver-rev < 3.1.5-r1 ), affects ('alpha', 'amd64', 'hppa', 'ia64', 'ppc', 'ppc-macos', 'ppc64', 'sparc', 'x86') app-text/tetex-2.0.2-r5: vulnerable via glsa(200603-02) ( ver-rev < 2.0.2-r8 ), affects ('alpha', 'amd64', 'arm', 'hppa', 'ia64', 'm68k', 'mips', 'ppc', 'ppc-macos', 'ppc64', 's390', 'sh', 'sparc', 'x86') app-text/wv2-0.2: vulnerable via glsa(200606-24) ( ver < 0.2.3 ), affects ('alpha', 'amd64', 'ppc', 'sparc', 'x86') app-text/wv2-0.2.1: vulnerable via glsa(200606-24) ( ver < 0.2.3 ), affects ('alpha', 'amd64', 'ppc', 'sparc', 'x86') app-text/wv2-0.2.2: vulnerable via glsa(200606-24) ( ver < 0.2.3 ), affects ('alpha', 'amd64', 'ia64', 'ppc', 'ppc64', 'sparc', 'x86') Please, clean up the above. Thanks!
This really doesn't need tetex-3 go stable first. The only thing that's need is mips stabilizing app-text/tetex-2.0.2-r8 or -r9, the rest can just go now... ;)
For tetex, we'll make a stable request of tetex-2.0.2-r9 at the same time than tetex-3 in order to avoid stable people recompiling whole tetex two times in a row. If everything goes according to plan, this should happen in about a week. As for the rest, ptex was already done and I cleaned cstetex, pstotext and wv2.
(In reply to comment #2) > For tetex, we'll make a stable request of tetex-2.0.2-r9 This doesn't need 2.0.2-r9 stable, rather needs mips keyword dropped altogether (see Bug 124511 Comment #8 and following for the fun). Re-asssigning to mips folks.
With all due respect, I think it's stupid to drop mips keyword for tetex. LaTeX is a very important piece of software for many people, and as far as I know, there is no mips-specific bug on tetex. It's also maintained (by the text-markup team), so I really don't see any reason to drop the keyword.
I agree nattfodd! As I said in that bug, mips should get their act together :-) It is really not that hard. My bet would be that tetex works perfectly on mips, but again until someone actually tries it out we won't know.
@mips - please drop your keywords on this package, this doesn't go anywhere.
15 months later, nothing. As such, I'm asking security to remove the vulnerable versions (now they have loads of more known issues because of recent bugs) due to total lack of interest from mips.
(In reply to comment #7) > 15 months later, nothing. As such, I'm asking security to remove the vulnerable > versions (now they have loads of more known issues because of recent bugs) due > to total lack of interest from mips. better just drop any keyword but mips. It is well known that they're always slacking, dont care about security bugs etc. Just killing mips on tetex will entirely break the tree, probably pissing off much more people that you can imagine. Think about repoman errors for the hundreds of ebuilds that have virtual/tetex as a dependency...
(In reply to comment #8) The only thing that breaks is kde-base/kdegraphics-3.5.5-r1 and virtual/latex-base-1.0 - which is trivially solvable by use.masking USE=tetex on mips.
(In reply to comment #9) > (In reply to comment #8) > > The only thing that breaks is kde-base/kdegraphics-3.5.5-r1 and > virtual/latex-base-1.0 - which is trivially solvable by use.masking USE=tetex > on mips. > still not a reason to be aggressive and remove functionalities imho; let them just do what they want. I wouldnt recommend anybody to use gentoo stable mips, what makes "stable" mips rather useless, but that's another story. It is well known that tetex 2 has been unsupported for ages, so I suppose mips is aware of that; and if they have interest in having a sane tex distribution, they'd better go with texlive. And I'm sorry but the borkage it will cause is not limited to 2 ebuilds that could be fixed by use masking. Check latex2html, this one will be broken. @security: feel free to drop all keywords on tetex 2 but mips; it is full of security holes, has probably tons of bugs, so people shouldn't use it anyway.
(In reply to comment #10) > And I'm sorry but the borkage it will cause is not limited to 2 ebuilds that > could be fixed by use masking. Check latex2html, this one will be broken. I didn't suggest to drop all mips keywords, I'm suggesting to drop the vulnerable versions, i.e., drop *stable* mips keyword. And yeah, I *did* check the whole tree, the only things broken are the ones in Comment #9.
(In reply to comment #11) > (In reply to comment #10) > > And I'm sorry but the borkage it will cause is not limited to 2 ebuilds that > > could be fixed by use masking. Check latex2html, this one will be broken. > > I didn't suggest to drop all mips keywords, I'm suggesting to drop the > vulnerable versions which nowadays means tetex-2*, which includes mips and ~mips...
(In reply to comment #12) > which nowadays means tetex-2*, which includes mips and ~mips... OK. Sticking the following to default-linux/mips/package.use.mask gets us rid of any need for tetex stuff on mips, without any breakage in the tree whatsoever: app-text/docbook-sgml-utils tetex app-text/sgmltools-lite tetex dev-python/pyopenssl doc tetex media-libs/t1lib doc kde-base/kdegraphics tetex media-libs/freetype tetex media-libs/libcaca doc Tested with the following ebuilds masked on mips: app-text/jadetex, app-text/tetex, dev-tex/aastex, dev-tex/latex2html, virtual/latex-base Sounds pretty easy to me, and definitely better than keeping vulnerable dead stuff in the tree indefinitely.
(In reply to comment #13) > (In reply to comment #12) > > which nowadays means tetex-2*, which includes mips and ~mips... > > OK. Sticking the following to default-linux/mips/package.use.mask gets us rid > of any need for tetex stuff on mips, without any breakage in the tree > whatsoever: Of course it's possible to kill tetex on mips with use.masking & droping keywords on some packages, but I still think that should be mips team (if any) decision. What's the problem with having vulnerable ebuilds keyworded only for mips ? I still think this is the most pragmatic thing to do. mips can have vulnerable ebuilds in stable or testing, if they don't dare to do proper testing, I couldn't care less. However, removing features and droping keywords on packages that (should) have been tested is a regression. And this is being too aggressive imho, while we have other means of stating that tetex-2 is totally unsupported.
Tex and cstetex have been taken care of, there's still ptex left, but once it's done, I think we can close this one.
(In reply to comment #15) > Tex and cstetex have been taken care of, there's still ptex left, but once it's > done, I think we can close this one. nah, tetex-3 is still not stable on mips :-/
@mips: ZOMG can you finally decide whether you want the tetex thing or nor, you are we going to wait for 2 years anniversary here?!
mips has no stable keywords anymore...can we close this bug now?
(In reply to comment #18) > mips has no stable keywords anymore...can we close this bug now? No we can't close this bug until all vulnerable junk is out of the tree.
Normally Security don't force the removal of vulnerable versions from the tree, so at first sight I don't really see why we would still want this bug.
Haven't checked whether anything changed since Comment #13 has been posted wrt the required package.use.mask stuff, and have no intention to waste more time on this. To sum this up, I'm tired of waiting for Godot, closing this bug, ktnxbye.
