Bug 18142 - new balsa2-version with security fix
|
Bug#:
18142
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: major
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: gnome@gentoo.org
|
Reported By: dobradovic@gmx.de
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: new balsa2-version with security fix
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2003-03-25 05:58 0000
|
Yesterday a new version of balsa was released including a security fix which is
related to rmutts recent buffer overflow, as balsa uses libmutt. I think this
should be worth the immediate upgrade in portage.
I made an ebuild based on the curren 2.0.9 one including support for the new
GPG-feature through the "crypt" USE variable.
Not sure what priority to give it, so I'll stick to "enhancement".
Balsa 1.4 is also affected by the buffer overflow, but portage is way behind
here, the new version is 1.4.3, but I can't test it as I have none of the
related Gnome1-stuff.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
reporter sorry this took like forever again. Both versions added to ~ . Arch
please test and move to stable respective versions for your arch, so i can
close this one.
I'm running it for a month now with absolutely no problems new in this version
compared to 2.0.9, diplomaticly said. :)
GPG-support is primitive for this version, but fully functional so far. In
retrospect there's a little bug in the ebuild.
for crypt, the dependency should be "=app-crypt/gpgme-0.3.14" only. Newer
versions won't work (0.4.0 popped up in portage-testing), and gpg itself will
be triggered by gpgme, and therefor doesn't need to be included.
forgot to mention I only tested x86... but I guess you would have guessed that
correctly.
since gpg support is still considered experimental, i didn't add it to the
ebuild just yet.
As balsa 2.0.10 was recently marked stable across all arches to fix a security
bug, it should fix this problem. balsa-2.0.10 and dependencies are marked
stable on sparc.
well, not really.. you should also mark 1.4.3 stable
Ahh, thanks for pointing that out. It has been marked stable for sparc.
I think you are correct to consider gpgme as non-stable yet, but wouldn't it be
a good idea to get it into "testing = ~x86"? I thought that's the idea behind
it.
So you could keep two parallel ebuilds of balsa, adding "-r1" with gpgme. If
you ever have to change the stable one, mark it "-r2" and bump the testing one
to "-r3". No good? :)
common misconception, ~x86 is for known stable stuff that hasn't been tested
well, not for experimental stuff. And revision bumping that way makes for
unreliable ebuilds (someone has a problem, i ask them for exact version, they
say -r2 , but what r2 is that exactly .. the new stable or the former
'testing').
Nope as it stands right now, people who want it should enable it themselves
(not like that is a big deal).
oh, didn't know that.
There's so much stuff in ~x86 I can't even compile... epiphany for example. *g* misunderstanding by me. So I should also send bug reports for non-perfect ~x86 - stuff?
And yes, who really wants it can hack it quickly. :) next balsa will have widely perfectioned gpg-support.
epipiphany doesnt compile ? if you have a proper 1.3 mozilla it should be no
problem, but feel free to open a bug about it.
closing this one, ppc also please test and mark stable as requested !
