<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>18142</bug_id>
          
          <creation_ts>2003-03-25 05:58 0000</creation_ts>
          <short_desc>new balsa2-version with security fix</short_desc>
          <delta_ts>2003-05-05 20:34:17 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Ebuilds</component>
          <version>unspecified</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>major</bug_severity>
          <target_milestone>1.4</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>dobradovic@gmx.de</reporter>
          <assigned_to>gnome@gentoo.org</assigned_to>
          <cc>ppc@gentoo.org</cc>
    
    <cc>sparc@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>dobradovic@gmx.de</who>
            <bug_when>2003-03-25 05:58:14 0000</bug_when>
            <thetext>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 &quot;crypt&quot; USE variable.

Not sure what priority to give it, so I&apos;ll stick to &quot;enhancement&quot;.
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&apos;t test it as I have none of the
related Gnome1-stuff.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dobradovic@gmx.de</who>
            <bug_when>2003-03-25 05:59:40 0000</bug_when>
            <thetext>Created an attachment (id=9792)
the new ebuild
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>foser@gentoo.org</who>
            <bug_when>2003-04-25 08:36:56 0000</bug_when>
            <thetext>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.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dobradovic@gmx.de</who>
            <bug_when>2003-04-25 10:21:38 0000</bug_when>
            <thetext>I&apos;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&apos;s a little bug in the ebuild.
for crypt, the dependency should be &quot;=app-crypt/gpgme-0.3.14&quot; only. Newer versions won&apos;t work (0.4.0 popped up in portage-testing), and gpg itself will be triggered by gpgme, and therefor doesn&apos;t need to be included.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dobradovic@gmx.de</who>
            <bug_when>2003-04-25 10:23:13 0000</bug_when>
            <thetext>forgot to mention I only tested x86... but I guess you would have guessed that correctly.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>foser@gentoo.org</who>
            <bug_when>2003-04-25 12:28:30 0000</bug_when>
            <thetext>since gpg support is still considered experimental, i didn&apos;t add it to the ebuild just yet.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>weeve@gentoo.org</who>
            <bug_when>2003-05-02 19:10:32 0000</bug_when>
            <thetext>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.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>foser@gentoo.org</who>
            <bug_when>2003-05-02 20:08:35 0000</bug_when>
            <thetext>well, not really.. you should also mark 1.4.3 stable</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>weeve@gentoo.org</who>
            <bug_when>2003-05-02 22:45:08 0000</bug_when>
            <thetext>Ahh, thanks for pointing that out.  It has been marked stable for sparc.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dobradovic@gmx.de</who>
            <bug_when>2003-05-03 11:51:46 0000</bug_when>
            <thetext>I think you are correct to consider gpgme as non-stable yet, but wouldn&apos;t it be a good idea to get it into &quot;testing = ~x86&quot;? I thought that&apos;s the idea behind it.

So you could keep two parallel ebuilds of balsa, adding &quot;-r1&quot; with gpgme. If you ever have to change the stable one, mark it &quot;-r2&quot; and bump the testing one to &quot;-r3&quot;. No good? :)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>foser@gentoo.org</who>
            <bug_when>2003-05-03 13:03:55 0000</bug_when>
            <thetext>common misconception, ~x86 is for known stable stuff that hasn&apos;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 &apos;testing&apos;).

Nope as it stands right now, people who want it should enable it themselves (not like that is a big deal).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dobradovic@gmx.de</who>
            <bug_when>2003-05-03 14:50:09 0000</bug_when>
            <thetext>oh, didn&apos;t know that.
There&apos;s so much stuff in ~x86 I can&apos;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.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>foser@gentoo.org</who>
            <bug_when>2003-05-03 17:06:22 0000</bug_when>
            <thetext>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.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>foser@gentoo.org</who>
            <bug_when>2003-05-05 20:34:17 0000</bug_when>
            <thetext>closing this one, ppc also please test and mark stable as requested !</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>9792</attachid>
            <date>2003-03-25 05:59 0000</date>
            <desc>the new ebuild</desc>
            <filename>balsa-2.0.10.ebuild</filename>
            <type>text/plain</type>
            <data encoding="base64">IyBDb3B5cmlnaHQgMTk5OS0yMDAzIEdlbnRvbyBUZWNobm9sb2dpZXMsIEluYy4KIyBEaXN0cmli
dXRlZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCB2
MiBvciBsYXRlcgojICRIZWFkZXI6IC9ob21lL2N2c3Jvb3QvZ2VudG9vLXg4Ni9uZXQtbWFpbC9i
YWxzYS9iYWxzYS0yLjAuOS1yMS5lYnVpbGQsdiAxLjEgMjAwMy8wMy8wOCAxODo0MzoyOSBmb3Nl
ciBFeHAgJAoKaW5oZXJpdCBnbm9tZTIgZXV0aWxzCgpJVVNFPSJzc2wgZ3RraHRtbCBwZXJsIGxk
YXAgY3J5cHQiCkRFU0NSSVBUSU9OPSJFbWFpbCBjbGllbnQgZm9yIEdOT01FIgpTUkNfVVJJPSJo
dHRwOi8vYmFsc2EuZ25vbWUub3JnLyR7UH0udGFyLmJ6MiIKSE9NRVBBR0U9Imh0dHA6Ly9iYWxz
YS5nbm9tZS5vcmciCgpTTE9UPSIyIgpMSUNFTlNFPSJHUEwtMiIKS0VZV09SRFM9Ing4NiB+cHBj
IH5zcGFyYyIKClJERVBFTkQ9Im5ldC1tYWlsL21haWxiYXNlCgk+PWRldi1saWJzL2dsaWItMgoJ
Pj14MTEtbGlicy9ndGsrLTIKCT49bmV0LWxpYnMvbGliZXNtdHAtMC44LjExCgk+PWdub21lLWJh
c2UvbGliZ25vbWUtMgoJPj1nbm9tZS1iYXNlL2xpYmdub21ldWktMgoJPj1nbm9tZS1iYXNlL2du
b21lLXZmcy0yCgk+PWdub21lLWJhc2UvbGliZ25vbWVwcmludC0yLjEuNAoJPj1nbm9tZS1iYXNl
L2xpYmdub21lcHJpbnR1aS0yLjEuNAoJPj1hcHAtdGV4dC9hc3BlbGwtMC41MAoJc3NsPyAoIGRl
di1saWJzL29wZW5zc2wgKQoJcGVybD8gKCA+PWRldi1saWJzL2xpYnBjcmUtMy40ICkKCWd0a2h0
bWw/ICggPj1nbm9tZS1leHRyYS9saWJndGtodG1sLTIgKQoJbGRhcD8gKCBuZXQtbmRzL29wZW5s
ZGFwICkKCWNyeXB0PyAoIGFwcC1jcnlwdC9nbnVwZyApCgljcnlwdD8gKCA+PWFwcC1jcnlwdC9n
cGdtZS0wLjMuMTQgKSIKCkRFUEVORD0iZGV2LXV0aWwvcGtnY29uZmlnCglzeXMtZGV2ZWwvZ2V0
dGV4dAoJPj1hcHAtdGV4dC9zY3JvbGxrZWVwZXItMC4xLjQKCSR7UkRFUEVORH0iCgpzcmNfY29t
cGlsZSgpIHsKCWxvY2FsIG15Y29uZgoJdXNlIHNzbCBcCgkJJiYgbXljb25mPSIke215Y29uZn0g
LS13aXRoLXNzbCIgXAoJCXx8IG15Y29uZj0iJHtteWNvbmZ9IC0td2l0aG91dC1zc2wiIAoJdXNl
IGd0a2h0bWwgXAoJCSYmIG15Y29uZj0iJHtteWNvbmZ9IC0td2l0aC1ndGtodG1sIiBcCgkJfHwg
bXljb25mPSIke215Y29uZn0gLS13aXRob3V0LWd0a2h0bWwiCgl1c2UgcGVybCBcCgkJJiYgbXlj
b25mPSIke215Y29uZn0gLS1lbmFibGUtcGNyZSIgXAoJCXx8IG15Y29uZj0iJHtteWNvbmZ9IC0t
ZGlzYWJsZS1wY3JlIgoJdXNlIGxkYXAgXAoJCSYmIG15Y29uZj0iJHtteWNvbmZ9IC0tZW5hYmxl
LWxkYXAiIFwKCQl8fCBteWNvbmY9IiR7bXljb25mfSAtLWRpc2FibGUtbGRhcCIKCXVzZSBjcnlw
dCBcCgkJJiYgbXljb25mPSIke215Y29uZn0gLS1lbmFibGUtZ3BnbWUiCgoJbGlibXV0dC9jb25m
aWd1cmUgXAoJCS0tcHJlZml4PS91c3IgXAoJCS0taG9zdD0ke0NIT1NUfSBcCgkJLS13aXRoLW1h
aWxwYXRoPS92YXIvbWFpbCB8fCBkaWUgImNvbmZpZ3VyZSBsaWJtdXR0IGZhaWxlZCIKCgkjIHRo
cmVhZHMgZGlhYmxlZCBiZWNhdXNlIG9mIDE3MDc5CgkjbXljb25mPSIke215Y29uZn0gLS1lbmFi
bGUtdGhyZWFkcyIKCW15Y29uZj0iJHtteWNvbmZ9IC0tZGlzYWJsZS10aHJlYWRzIgoKCWVjb25m
ICR7bXljb25mfSB8fCBkaWUgImNvbmZpZ3VyZSBiYWxzYSBmYWlsZWQiCgllbWFrZSB8fCBkaWUg
ImVtYWtlIGZhaWxlZCIKfQoKc3JjX2luc3RhbGwgKCkgewoJbG9jYWwgbXlpbnN0CglteWluc3Q9
Imdub21lY29uZmRpcj0ke0R9L2V0YyBcCgkJZ25vbWVkYXRhZGlyPSR7RH0vdXNyL3NoYXJlIgoK
CWVpbnN0YWxsICR7bXlpbnN0fSB8fCBkaWUgIm1ha2UgaW5zdGFsbCBmYWlsZWQiCglkb2RvYyBB
VVRIT1JTIENPUFlJTkcgQ2hhbmdlTG9nIEhBQ0tJTkcgSU5TVEFMTCBORVdTIFJFQURNRSBUT0RP
Cglkb2NpbnRvIGRvY3MKCWRvZG9jIGRvY3MvKgp9Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>