gmane.linux.gentoo.security

Prince, Samuel is out of the office.

2008-08-21T03:03:43

I will be out of the office starting 18/08/2008 and will not return until 29/08/2008. I will have limited access to my email while away from the office. Should you require immediate assistance during that time, please contact ricardo.buckham< at >jm.pwc.com or melissa.a.mclymont< at >jm.pwc.com. _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Reporting restricted bugs works again

Robert Buchholz — 2008-08-20T21:37:04

Hello all, as you might be aware, the Gentoo Security Team encourages users to report security vulnerabilities or findings of code audits that are not yet public in our Bugzilla under the 'Gentoo Security' component. However, as we learned earlier, it was not possible for users to restrict access to such security bugs, which would lead to a public disclosure of all details. This issue is now corrected, as an over-careful restriction in our template was lifted. I'd like to thank Robin H. Johnson for promptly investigating and resolving the issue! You can find details on how to report confidential bugs in section 3 on this site: http://www.gentoo.org/security/en/ Regards, Robert

(unknown)

Joe Nolting — 2008-08-06T14:12:56

Re: Security project meeting summary

Robert Buchholz — 2008-07-29T02:13:38

GLSA support has also been integrated into Portage 2.2, so you can do something along the lines of # emerge --update < at >security Robert

Re: Security project meeting summary

Bill — 2008-07-28T23:33:31

This doesn't work anymore? 1. emerge --sync (emerge-webrsync) 2. glsa-check -p affected 3. glsa-check -f affected 4. env-update 5. revdep-rebuild Bill

Re: Security project meeting summary

Aleksey V Lazar — 2008-07-28T22:08:27

Hello, Robert: Robert Buchholz wrote: Are you saying that security mask entries would go into the package.security.mask and feature/other to package.mask? I think this would make sense. I described in some more detail what I was thinking about in my previous post to this list. To answer your question, I think a feature like this would be very useful, because it would remove barriers for identifying packages with security issues. For example, I don't update my gentoo system daily, but I would update it as often as necessary to keep it secure. Currently (to the best of my understanding) there is no easy way (e.g.: an /emerge/ option) to identify and update only the packages that have security fixes. I would have to do some digging to find out what packages and evaluate each package separately. So I think there would be value in separating security masking from other types. To summarize, I think this would accomplish the following: 1. Easily identify packages masked for security reasons. 2.

Re: Security project meeting summary

Aleksey V Lazar — 2008-07-24T17:20:49

Pierre-Yves Rofes wrote: I was thinking more along the lines of adding a special mark to the list that currently includes "~", "+" and "M". Let's say it would be "!". This mark could then be used for package versions with security problems. I don't know if this is technically possible, but I could see "!" used in conjunction with the "~", "+" or "M" to alert/indicate a security issue, like "~!", or "+!" or "M!". I think this is what I meant. Thanks. Aleksey

Re: Security project meeting summary

Robert Buchholz — 2008-07-22T19:04:14

Sorry, I do not understand the point you are trying to make. Nethack has an unresolved security bug, and if you want to install it anyway, put it in your /etc/portage/package.unmask -- as described in "man emerge". I do not see the gain by setting up a system that would completely ignore *all* security-related package masks. Robert

Re: Security project meeting summary

Paige Thompson — 2008-07-22T18:01:04

misfit[1004]:~% sudo emerge -uva nethack Password: These are the packages that would be merged, in order: Calculating dependencies | !!! All ebuilds that could satisfy "games-roguelike/nethack" have been masked. !!! One of the following masked packages is required to complete your request: - games-roguelike/nethack-3.4.3-r1 (masked by: package.mask) /usr/portage/profiles/package.mask: # Tavis Ormandy gentoo.org> (21 Mar 2006) # masked pending unresolved security issues #125902 For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. misfit[1005]:~% On Tue, Jul 22, 2008 at 3:42 AM, Robert Buchholz gentoo.org> wrote:

Re: Security project meeting summary

Robert Buchholz — 2008-07-22T10:42:41

Hi Aleksey, since entries package.mask only contain free text description as an additional information, such a feature would require the package manager to decide which entries are security maskings, and which are feature maskings. While that could be done using restrictions/conventions within the text, I am sure our package manager developers would disagree with such a design. A "package.security.mask" file might be more appropriate for that. My question now is, why would you want such a thing? Masked packages all have different reasons to be there, and you should decide to use one on a case-by-case basis. Regards, Robert

Re: Security project meeting summary

Aleksey V Lazar — 2008-07-21T19:04:52

Hello. Would it be reasonable to suggest adding a ~security (or something like it) flag to denote packages masked for security reasons? Thanks. Aleksey Matthias Geerdsen wrote:

Security project meeting summary

Matthias Geerdsen — 2008-07-21T18:49:16

Security project meeting - Monday, 2008-07-14, 19:00 UTC

Matthias Geerdsen — 2008-07-12T23:18:29

Hi everyone, the security project will hold a public meeting in #gentoo-security this monday, 2008-07-14 at 19:00 UTC (21:00 CEST). The tentative agenda looks as follows: 1) Project status 2) Recruitment 3) Delays in bug resolution/GLSA publication 4) GLSA related issues 4.1) new date format 4.2) slot support 5) Handling of CVE identifiers in bugs 6) Possible changes to the Vulnerability Policy 6.1) Rating for "insecure creation of temporary files" 6.2) Rating for "SQL injection" 7) Security support for games 8) Any other topic Any changes to the agenda as well as related info can be found at [1]. [1]

Re: ssl weak key generation (supposed to effectonly debian)

Raphael Marichez — 2008-05-21T16:37:49

Hi, - when a vulnerability has been found inside the package, the package is vulnerable, it's not claimed to be distro-specific, and by default you are right in assuming that every distro is affected. - when a vulnerability has been found in a *distro-specific* patch or script (or ebuild (or Windows-specific version ) ), the vulnerability is claimed to reside in the distro scripts, or in the distro patch. So it's distro-specific. each linux distribution can not handle every other-distro-specific vulnerability. Gentoo has sometimes gentoo-specific vulnerabilities [1], and Debian too. Debian does not issue any statement that they are not affected by a Gentoo-specific vulnerability. No distro does that. And there would be a lot of other distributions to monitor [2]... That would really be a mess. [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1383 [2] http://distrowatch.com/dwres.php?resource=major http://distrowatch.com/dwres.php?resource=cd http://distrowatch.com/dwres.php?resource=firewa

Re: ssl weak key generation (supposed to effect only debian)

Byron — 2008-05-18T01:10:56

< ....... > It's something of a "lesser of two evils" situation. In the absence of evidence either way, the only habit that would be worse is assuming that any distribution is not affected, simply because they do not publicly state that they are. Having said that, it's good to know that apparently Gentoo is not impacted.

Re: ssl weak key generation (supposed to effect only debian)

Robert Buchholz — 2008-05-17T11:15:07

Hi Peter, On Saturday, 17. May 2008, Peter Schneider-Kamp wrote: I could not find where these advisories are published on their site, I guess they are not publicly distributed. The Gentoo Security Team internally reviewed patches to our "dev-libs/openssl" package right when we heard about the issue via a private channel. We could confirm that the patch is not included in our distribution. Furthermore, additional tests showed that there is no dependence only on PID when generating keys, and that some Gentoo produced keys are not included in the blacklist (which you also confirmed). We issued no formal statement*, because Debian was so clear about the scope of the vulnerability. To think that any distribution is affected, simply because they do not publicly state they are not, is a bad habit. Other CERTs usually contact us for vendor statements when they think we are affected by one vulnerability. The only thing compromising DSA keys generated on Gentoo is the usage of the private key on an a

ssl weak key generation (supposed to effect only debian)

Peter Schneider-Kamp — 2008-05-17T09:08:36

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the recently publicized SSL weak key generation for debian-based systems (c.f. http://www.debian.org/security/key-rollover/) has lead our university computing center to retract our Gentoo-generated SSL keys based on an advisory from the German DFN cert :-( I have not found any information about whether this might also affect Gentoo systems. A test with the Perl script from http://security.debian.org/project/extra/dowkd/dowkd.pl.gz does not show vulnerability: ~ summary: keys found: 2, weak keys: 0 So I guess that Gentoo-generated keys are not affected. Still it would be nice to have an official statement to prevent official certification bodies from retracting valid Gentoo-generated keys. Regards, Peter - -- Peter Schneider-Kamp mailto:psk< at >informatik.rwth-aachen.de LuFG Informatik II http://verify.rwth-aachen.de/psk RWTH Aachen phone: +49 241 80-21211 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with

Re: Portage rsync security

Raphael Marichez — 2008-04-14T16:34:03

Hi all, indeed the patches are MD5-checked against the Manifest files in the portage tree itself, so i can't assure any integrity on the patches that rely in the portage tree, in the case my rsync server is compromised or spoofed. There is no point in enforcing cryptography on the transport layer, since this would prevent from making one's own local mirror like described in : http://www.gentoo.org/doc/en/rsync.xml#doc_chap2 Since the Gentoo main rsync mirrors list will change sometimes, it's also difficult (but still feasible) to maintain a secured transport with each of the main mirrors, with /etc/hosts, netfilter, or whatever that is IP-based. And that does not protect from the remote server compromise. The integrity check is currently being implemented at the data level, not the host level, through the way of GPG signatures of Manifest files: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6 As for today, 2483 Manifest files are signed, and 10065 are not. Obviously, the most

Re: Prince, Samuel is out of the office.

brant williams — 2008-04-01T21:07:08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Just the right message for a security-minded list! And on April Fool's! =) This reminds me of a recent Wired article[1]. Cheers! [1] http://www.wired.com/politics/security/commentary/securitymatters/2008/03/securitymatters_0320 brant williams FCAA CDCA 20BC 3925 D634 F5C4 7420 6784 4DEB 6002 On Tue, 1 Apr 2008, samuel.prince< at >jm.pwc.com wrote: -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH8qP/dCBnhE3rYAIRCLA+AKCcM3dwsja4FOUCHSS+03PRfU7e+QCaA7EV lbDLhLHUONvzis6i/AiI1lM= =Qx0m -----END PGP SIGNATURE-----

Prince, Samuel is out of the office.

2008-04-01T21:01:02

I will be out of the office starting 03/31/2008 and will not return until 04/07/2008. I will respond to your message when I return. _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Re: gpg keys; GSWoT & PGP Global Directory Key

Eric Martin — 2008-04-01T18:05:29

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias Bethke wrote: | Hi Eric, | on Fri, Mar 28, 2008 at 03:13:43PM -0400, you wrote: |> I'm seeing a bunch of keys in my keyring with GSWoT(1) and PGP Global |> Directory(2) signatures on them. Obviously both websites encourage you |> to download their keys and trust them. While I realize what keys you |> trust is totally up to you, I'm wondering what fellow people do. My |> idea was to /maybe/ add them in as moderates that way they don't run my |> keyring for me, but still vouch for people where necessary. | | As far as I can see, the PGP Global Directory does no verification apart | from checking that an email address exists, so its signature isn't worth | much for the WoT. The GSWoT signatures on the other hand mean the owner | of the key has been personally checked by an introducer. It's a matter | of taste but I usually don't sign role account keys, I think they should | be signed by members of the institution (the introducers in this case) | whom I