[gentoo-dev] Re: Some ideas on how to reduce territoriality
Ryan Hill wrote: Pushing to eliminate one of these options is going to make one group or the other very annoyed. ++ When in doubt: mechanism, not policy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: app-cdr/kover
# Wulf C. Krueger [EMAIL PROTECTED] (21 Aug 2007) # Stable version doesn't compile, unstable version is partly broken. # Application is conceptionally wrong. More details on bug 187251. # Use app-cdr/koverartist instead. # Masked for removal in 30 days. app-cdr/kover signature.asc Description: This is a digitally signed message part.
[gentoo-dev] SSL certificates in binary packages
Hi, I use the gentoo framework to build binary packages. I noticed that most packages creates the ssl certificate during src_install(). This makes all binary packages contain the ssl certs which is a security threat. The net-nds/openldap package has understood this and calls docert from pkg_postinst() and even includes this comment: # You cannot build SSL certificates during src_install that will make # binary packages containing your SSL key, which is both a security risk # and a misconfiguration if multiple machines use the same key and cert. # Additionally, it overwrites The net-im/ejabberd seems to create ssl cert from antoher script. The vulnerable packages are: app-admin/conserver mail-mta/postfix net-analyzer/sguil-server net-firewall/nufw net-ftp/netkit-ftpd net-irc/ptlink-ircd net-irc/unrealircd net-mail/cyrus-imapd net-mail/cyrus-imspd net-mail/dovecot net-misc/stunnel net-nntp/inn www-servers/nginx Should I create a bug for every vulnerable package? From a binary packagers perspective I would really prefer to create the certs from init.d script. Thanks! Natanael Copa -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] SSL certificates in binary packages
On 8/21/07, Natanael Copa [EMAIL PROTECTED] wrote: Hi, I use the gentoo framework to build binary packages. I noticed that most packages creates the ssl certificate during src_install(). This makes all binary packages contain the ssl certs which is a security threat. The net-nds/openldap package has understood this and calls docert from pkg_postinst() and even includes this comment: # You cannot build SSL certificates during src_install that will make # binary packages containing your SSL key, which is both a security risk # and a misconfiguration if multiple machines use the same key and cert. # Additionally, it overwrites The net-im/ejabberd seems to create ssl cert from antoher script. The vulnerable packages are: app-admin/conserver mail-mta/postfix net-analyzer/sguil-server net-firewall/nufw net-ftp/netkit-ftpd net-irc/ptlink-ircd net-irc/unrealircd net-mail/cyrus-imapd net-mail/cyrus-imspd net-mail/dovecot net-misc/stunnel net-nntp/inn www-servers/nginx Should I create a bug for every vulnerable package? From a binary packagers perspective I would really prefer to create the certs from init.d script. Generating certs from init.d is a bad idea IMHO. It makes it way too easy to automatically generate new certs in the event that old ones are moved (if you are talking about the service starting, detecting no certs, generating some, then using them). I guess you could do like /etc/init.d/SERVICE certgen, but that too is probably a hack (not really what init scripts are for). I personally would generate the certs on a trusted server/workstation and then push them to the machine post-install using slack or cfengine or puppet. I don't see why (in a generic package like a gentoo ebuild) you would do anything but create a generic cert 'so it works out of the box'. You are certainly entitled to edit the ebuild's postinst to do whatever :) PS: I'll try to get to these tonight, you can just file a tracker bug for them. Thanks! Natanael Copa -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] SSL certificates in binary packages
On Tue, Aug 21, 2007 at 04:12:32PM +0200, Natanael Copa wrote: I use the gentoo framework to build binary packages. I noticed that most packages creates the ssl certificate during src_install(). This makes all binary packages contain the ssl certs which is a security threat. I filed bug #174759 to the security team back in April on this issue, and then fixed the openldap package where I had originally found it. Anybody using binpkgs obtained from a public repository that contain SSL certs should ensure that they regenerate the SSL certs on each machine. For packages, there are two possible fixes: 1. Move the docert call into pkg_postinst. 2. Provide scripts that generate certs (courier-imap and qmail do this). -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgppzsT4NuWk7.pgp Description: PGP signature
Re: [gentoo-dev] SSL certificates in binary packages
On Tuesday 21 August 2007, Robin H. Johnson wrote: On Tue, Aug 21, 2007 at 04:12:32PM +0200, Natanael Copa wrote: I use the gentoo framework to build binary packages. I noticed that most packages creates the ssl certificate during src_install(). This makes all binary packages contain the ssl certs which is a security threat. I filed bug #174759 to the security team back in April on this issue, and then fixed the openldap package where I had originally found it. Anybody using binpkgs obtained from a public repository that contain SSL certs should ensure that they regenerate the SSL certs on each machine. For packages, there are two possible fixes: 1. Move the docert call into pkg_postinst. there it is -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Status of xcb
Hi, With compiz 0.5.4, we get the first version that depends on xcb. While we still have an open bug asking for use-masking xcb https://bugs.gentoo.org/show_bug.cgi?id=174434 I'd like to open the question just the other way round: When can we make xcb default? And: How should I handle that? We don't have a feature like mask if use xcb isn't set, so it most probably means all compiz-versions from now on will be masked till we have xcb. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Status of xcb
On 05:58 Wed 22 Aug , Hanno Böck wrote: With compiz 0.5.4, we get the first version that depends on xcb. While we still have an open bug asking for use-masking xcb https://bugs.gentoo.org/show_bug.cgi?id=174434 I'd like to open the question just the other way round: When can we make xcb default? We're kinda screwed till Java gets fixed. Yay for being held back by proprietary software, again. Check bug #156353 for Sun Java. And: How should I handle that? We don't have a feature like mask if use xcb isn't set, so it most probably means all compiz-versions from now on will be masked till we have xcb. You'll have to be annoying and use built_with_use() + die() if unset. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-portage-dev] [PATCH] getbinpkg - trivial interface enhancements
This patch only makes sure that a newline is inserted before the 'Fetching binary packages info ...' line, and changes the yellow and green x's and o's to a single line, with a counter variable for each. Example: These are the packages that would be merged, in order: Calculating dependencies / Fetching binary packages info... cache miss: '532' --- cache hit: '0' -- DONE! I only did this because we use a binhost here on our network and the colors and extremely long string were pretty glaring. I added sys.stderr.flush() after each of the sys.stderr.write() lines to allow for updating the screen live. The preformance hit for flushing every write is fairly negligible on my machine which is a 2.5Ghz P4 w/ 1G of ram. YMMV. The version string on the patch is from the portage version I'm using and patched against, which is portage-2.1.3.5. Cheers, Mike Fuzzy Partin --- /usr/lib/portage/pym/getbinpkg.py 2007-08-14 09:22:46.0 -0500 +++ getbinpkg.py2007-08-21 10:01:22.0 -0500 @@ -544,13 +544,17 @@ sys.stderr.write(!!! +str(e)+\n) break # We may have metadata... now we run through the tbz2 list and check. - sys.stderr.write(yellow(cache miss: 'x')+ --- +green(cache hit: 'o')+\n) + ext_miss = 0 + ext_hit = 0 + sys.stderr.write(yellow(cache miss: '+str(ext_miss)+')+ --- +green(cache hit: '+str(ext_hit)+')+\r) binpkg_filenames = set() for x in tbz2list: x = os.path.basename(x) binpkg_filenames.add(x) if x not in metadata[baseurl][data]: - sys.stderr.write(yellow(x)) + ext_miss += 1 + sys.stderr.write(yellow(cache miss: '+str(ext_miss)+')+ --- +green(cache hit: '+str(ext_hit)+')+\r) + sys.stderr.flush() metadata[baseurl][modified] = 1 myid = None for retry in xrange(3): @@ -572,7 +576,9 @@ elif verbose: sys.stderr.write(red(!!! Failed to retrieve metadata on: )+str(x)+\n) else: - sys.stderr.write(green(o)) + ext_hit += 1 + sys.stderr.write(yellow(cache miss: '+str(ext_miss)+')+ --- +green(cache hit: '+str(ext_hit)+')+\r) + sys.stderr.flush() # Cleanse stale cache for files that don't exist on the server anymore. stale_cache = set(metadata[baseurl][data]).difference(binpkg_filenames) if stale_cache:
