kernel.org status: establishing a PGP web of trust

kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Since the kernel.org status announcement last week a number of you
have contacted me about re-establishing credentials.  In order to
establish a proper PGP web of trust we need keys that are cross-signed
by other developers.  As such, we ask that you follow the following
steps:

1. Make sure your systems are uncompromised.  We will address specific
   recommended steps for that in a separate email.

2. Create a new PGP/GPG key, and also generate a key revocation
   certificate (but don't import it anywhere -- save it for the
   future) for your new key.  In the near future we are considering
   setting up an escrow service for key revocation certificates.

   I recommend using a 4096-bit RSA key.  Given how fast computers are
   these days, there is no reason to use a shorter key.  DSA keys
   should be considered obsolete; substantial weaknesses have been
   found in DSA.

   $ gpg --gen-key
   $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke

3. If you are reasonably certain that your old key has never been
   jeopardized, sign the new key with the old key.

   $ gpg -u <your old key ID> --sign-key <your new key ID>

   If you are *not* sure about your old keys, please revoke them if
   you haven't already done so (create a revocation certificate and
   import it into your keyring, then push the key to the key servers.)

   $ gpg -u <your old key ID> -o <your old key ID>.revoke --gen-revoke
   $ gpg --import <your old key ID>.revoke
   $ gpg --keyserver pgp.mit.edu --send-key <your old key ID>

4. Upload the signed keys to the keyserver system (I usually use
   pgp.mit.edu, but most of the keyservers sync with each other with
   roughly a 24-hour delay.)  By publishing the keys we make them
   available not only to kernel.org but for other uses, like signing
   email, and you can verify yourself by looking at http://pgp.mit.edu/
   if there is someone out there who has published a key with your name
   on it.  Furthermore, it allows us to tap other webs of trust already
   established.

   $ gpg --keyserver pgp.mit.edu --send-key <your key ID>

5. Get as many other kernel developers that you have physical access to
   to sign your key after verifying the fingerprint.  Verifying keys
   over the phone is OK if and only if you know them *extremely* well;
   think "would I be willing to testify in court that the person I
   talked to was X"?

   If you work in an office with multiple other Linux developers, it
   would be a very good thing to organize a local key signing.  We will
   do a key signing at Kernel Summit for the core kernel developers.

   A web site with recommendations for running a key signing:


http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html

   $ gpg --fingerprint <key ID>
   $ gpg --keyserver pgp.mit.edu --recv-key <their key ID>
   $ gpg -u <your key ID> --sign-key <their key ID>
   $ gpg --keyserver pgp.mit.edu --send-key <their key ID>
   $ gpg --keyserver pgp.mit.edu --recv-key <your key ID>

6. Please send me the key identifier and fingerprint to
   <keys@zytor.com>.  This is a temporary address until the kernel.org
   MX is ready to put back online; eventually we will probably have a
   web form interface for this.

	-hpa

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOhlXFAAoJEL2gYIVJO6zkc7MP/2Qb6iOGCMEd3ncV8N9Znqsf
nPYnjS7Eo8EafbC5A/Pe5UaqzVw3UrWAewTENUaNndXuTDRYhvt2SeQEbASpCTfG
Wr0WPzcrrnIOhJDk9WyLUIE+wR52Alq/EYmiRBDBNJmNqwo7SgXVpyDqMvLeH9IH
LCey68XfQ2WrD25p3a3zmi5woGuluQsUVYNJCB0yC1RpESJDO6GNx+tUWWR6kRk1
GmaUs0qrx9nHrycQZIq1pga3v/uxSvxr7pYAvLMLvl0pCFE+GbQ+wCMqpddOTA0/
0d5QVRqL1neCMGYUm+9Ff3AzzyaqTKHPOm6grnUp+M73+3FJIMzr3BOEIJnusJA5
vDPjHl8j3+LJXeTNNp3V/pmM89uc9vWjdyRoMyeufN2simC07csxh8E8s35hz3gj
z6tdch9ygHJt1rS3XuJva9p5kNm0ptMtbF1wWzJCci8Lo7iiMoj0GECyeIzvEbic
qG6sUfgIORGe3OH8MPCdmn2BY1y0Rz6rD05s1nZOBxOoYihrtDrnNC5MJl4+lvTW
7fzTFVzbjQO7Ybu/PqLeAJ4ieTFflbp4j7dI9dTKxHfTKQ+NT1YgiRpS7gcZeDhS
YmVKMmN5QpxFqMYhr9gc2S/6iYwRTP1juWMf0bxP9xiY/SaBhW8XrpyxE85svc+o
9j39P8QGHPb35HQ2HPgn
=PdWd
-----END PGP SIGNATURE-----

kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

[-- Attachment #1: Type: text/plain, Size: 4816 bytes --]

The compromise of kernel.org and related machines has made it clear that
some developers, at least, have had their systems penetrated.  As we
seek to secure our infrastructure, it is imperative that nobody falls
victim to the belief that it cannot happen to them.  We all need to
check our systems for intrusions.  Here are some helpful hints as
proposed by a number of developers on how to check to see if your Linux
machine might be infected with something:


0. One way to be sure that your system is not compromised is to simply
   do a clean install; we can all benefit from a new start sometimes.
   Before reinstalling any systems, though, consider following the steps
   below to learn if your system has been hit or not.

1. Install the chkrootkit package from your distro repository and see if it
   reports anything.  If your distro doesn't have the chkroot package,
   download it from:
	http://www.chkrootkit.org/

   Another tool is the ossec-rootcheck tool which can be found at:
	http://www.ossec.net/main/rootcheck

   And another one is the rkhunter program:
   	http://www.rootkit.nl/projects/rootkit_hunter.html
   [Note, this tool has the tendancy to give false-positives on some
   Debian boxes, please read /usr/share/doc/rkhunter/README.Debian.gz if
   you run this on a Debian machine]

2. Verify that your package signatures match what your package manager thinks
   they are.

   To do this on a rpm-based system, run the following command:
   	rpm --verify --all
   Please read the rpm man page for information on how to interpret the
   output of this command.

   To do this on a Debian based system, run the following bash snippet:
	dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n;
	fi; done > ~/tmp.txt
	for f in `cat ~/tmp.txt`; do debsums -s -a $f; done

   If you have a source-based system (Gentoo, LFS, etc.) you presumably
   know what you are doing already.

3. Verify that your packages are really signed with the distro's keys.

   Here's a bash snippet that can do this on a rpm based system to
   verify that the packages are signed with any key, not necessarily
   your distro's key.  That exercise is left for the reader:

	for package in `rpm -qa`; do
		sig=`rpm -q --qf '%{SIGPGP:pgpsig}\n' $package`
		if [ -z "$sig" ] ; then
			# check if there is a GPG key, not a PGP one
			sig=`rpm -q --qf '%{SIGGPG:pgpsig}\n' $package`
			if [ -z "$sig" ] ; then
				echo "$package does not have a signature!!!"
			fi
		fi
	done

   Unfortunately there is no known way of verifying this on Debian-based
   systems.

4. To replace a package that you find suspect, uninstall it and install
   it anew from your distro.  For example, if you want to reinstall the
   ssh daemon, you would do:
	$ /etc/init.d/sshd stop
	rpm -e openssh
	zypper install openssh	# for openSUSE based systems
	yum install openssh	# for Fedora based systems

   Ideally do this from a live cdrom boot, using the 'rpm --root' option
   to point rpm at the correct location.


5. From a liveCD environment, look for traces such as:
   a. Rogue startup scripts in /etc/rc*.d and equivalent directories.
   b. Strange directories in /usr/share that do not belong to a package.
      This can be checked on an rpm system with the following bash snippet:
	for file in `find /usr/share/`; do
		package=`rpm -qf -- ${file} | grep "is not owned"`
		if [ -n "$package" ] ; then
			echo "weird file ${file}, please check this out"
		fi
	done

6. Look for mysterious log messages, such as:
   a. Unexpected logins in wtmp and /var/log/secure*, quite possibly
      from legitimate users from unexpected hosts.
   b. Any program trying to touch /dev/mem.
   c. References to strange (non-text) ssh version strings in
      /var/log/secure*.  These do not necessarily indicate *successful*
      breakins, but they indicate *attempted* breakins which means your
      system or IP address has been targeted.

7. If any of the above steps show possible signs of compromise, you
   should investigate further and identify the actual cause.  If it
   becomes clear that the system has indeed been compromised, you should
   certainly reinstall the system from the beginning, and change your
   credentials on all machines that this machine would have had access
   to, or which you connected to through this machine.  You will need
   to check your other systems carefully, and you should almost
   certainly notify the administrators of other systems to which you
   have access.

Finally, please note that these hints are not guaranteed to turn up
signs of a compromised systems.  There are a lot of attackers out there;
some of them are rather more sophisticated than others.  You should
always be on the alert for any sort of unexpected behavior from the
systems you work with.


thanks,

greg k-h

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: kernel.org status: hints on how to check your machine for intrusion

[David Miller]

From: Greg KH <greg@kroah.com>
Date: Fri, 30 Sep 2011 16:59:24 -0700

> 1. Install the chkrootkit package from your distro repository and see if it
>    reports anything.  If your distro doesn't have the chkroot package,
>    download it from:
> 	http://www.chkrootkit.org/
> 
>    Another tool is the ossec-rootcheck tool which can be found at:
> 	http://www.ossec.net/main/rootcheck
> 
>    And another one is the rkhunter program:
>    	http://www.rootkit.nl/projects/rootkit_hunter.html
>    [Note, this tool has the tendancy to give false-positives on some
>    Debian boxes, please read /usr/share/doc/rkhunter/README.Debian.gz if
>    you run this on a Debian machine]

I quickly found that it gives false positives on Fedora15 too.

It thinks one is infected with Suckit.

It's check is essentially "strings /sbin/init | egrep HOME" which
triggers with:

	XDG_CONFIG_HOME
	XDG_DATA_HOME
	HOME=%s

I'm sure chkrootkit might be useful as a guide, but the seeming
pervasiveness of it's false positives make it much less useful than it
could be.

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Fri, Sep 30, 2011 at 09:15:20PM -0400, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Fri, 30 Sep 2011 16:59:24 -0700
> 
> > 1. Install the chkrootkit package from your distro repository and see if it
> >    reports anything.  If your distro doesn't have the chkroot package,
> >    download it from:
> > 	http://www.chkrootkit.org/
> > 
> >    Another tool is the ossec-rootcheck tool which can be found at:
> > 	http://www.ossec.net/main/rootcheck
> > 
> >    And another one is the rkhunter program:
> >    	http://www.rootkit.nl/projects/rootkit_hunter.html
> >    [Note, this tool has the tendancy to give false-positives on some
> >    Debian boxes, please read /usr/share/doc/rkhunter/README.Debian.gz if
> >    you run this on a Debian machine]
> 
> I quickly found that it gives false positives on Fedora15 too.
> 
> It thinks one is infected with Suckit.
> 
> It's check is essentially "strings /sbin/init | egrep HOME" which
> triggers with:
> 
> 	XDG_CONFIG_HOME
> 	XDG_DATA_HOME
> 	HOME=%s
> 
> I'm sure chkrootkit might be useful as a guide, but the seeming
> pervasiveness of it's false positives make it much less useful than it
> could be.

That's sad, but the combination of the three tools should give some
sense of what is going on if things are really valid or not, hopefully.

It was tough to write this in a way that would be applicable to the
large variety of systems we all use, so little differences like this
will happen.  Hopefully people take this as a guideline of things to do
to try to ensure the safety of a system.

thanks,

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

Hi Greg,

On Fri, Sep 30, 2011 at 04:59:24PM -0700, Greg KH wrote:
> The compromise of kernel.org and related machines has made it clear that
> some developers, at least, have had their systems penetrated.  As we
> seek to secure our infrastructure, it is imperative that nobody falls
> victim to the belief that it cannot happen to them.  We all need to
> check our systems for intrusions.  Here are some helpful hints as
> proposed by a number of developers on how to check to see if your Linux
> machine might be infected with something:

I would like to add here a few controls I ran on firewall and system logs,
that are easy to perform and which report few false positives :

  - check that communications between your local machines are expected ;
    for instance if you have an SSH bouncing machine, it probably receives
    tens of thousands of SSH connection attempts from outside every day,
    but it should never ever attempt to connect to another machine unless
    it's you who are doing it. So checking the firewall logs for SSH
    connections on port 22 from local machines should only report your
    activity (and nothing should happen when you sleep).

  - no SSH log should report failed connection attempts between your
    local machines (you do have your keys and remember your password).
    And if it happens from time to time (eg: user mismatch between
    machines), it should look normal to you. You should never observe
    a connection attempt for a user you're not familiar with (eg: admin).

     $ grep sshd /var/log/messages
     $ grep sshd /var/log/messages | grep 'Invalid user'

  - outgoing connections from your laptop, desktop or anything should
    never happen when you're not there, unless there is a well known
    reason (package updates, browser left open and refreshing ads). All
    unexpected activity should be analysed (eg: connections to port 80
    not coming from a browser should only match one distro mirror).
    This is particularly true for cheap appliances which become more
    and more common and are rarely secured. A NAS or media server, a
    switch, a WiFi router, etc... has no reason to ever connect anywhere
    without you being aware of it (eg: download a firmware update).

  - check for suspicious DNS requests from machines that are normally
    not accessed. A number of services perform DNS requests when
    connected to, in order to log a resolved address. If the machine
    was penetrated and the logs wiped, the DNS requests will probably
    still lie in the firewall logs. While there's nothing suspect from
    a machine that does tens of thousands DNS requests a day, one that
    does 10 might be suspect.

  - check for outgoing SMTP connections. Most machines probably never
    send any mail outside or route them through a specific relay. If
    one machine suddenly tries to send mails directly to the outside,
    it might be someone trying to steal some data (eg: mail ssh keys).

  - check for long holes in logs various service logs. The idea is that
    if a system was penetrated and the guy notices he left a number of
    traces, he will probably have wiped some logs. A simple way to check
    for this is to count the number of events per hour and observe huge
    variations. Eg:

       $ cut -c1-9 < /var/log/syslog |uniq -c
       8490 Oct  1 00
       7712 Oct  1 01
       8316 Oct  1 02
       6743 Oct  1 03
       7428 Oct  1 04
       7041 Oct  1 05
       7762 Oct  1 06
       6562 Oct  1 07
       7137 Oct  1 08
        160 Oct  1 09

    Activity looks normal here. Something like this however would be
    extremely suspect :

       8490 Oct  1 00
        712 Oct  1 01
       6743 Oct  1 03

  - check that you never observe in logs a local address that you
    don't know. For instance, if your reverse proxy is on a DMZ which
    is provided by the same physical switch as your LAN and your switch
    becomes ill and loses all its VLAN configuration, it them becomes
    easy to add an alias to the reverse-proxy to connect directly to
    LAN machines and bypass a firewall (and its logs).

  - it's always a good exercise to check for setuids on all your machines.
    You'll generally discover a number of things you did not even suspect
    existed and will likely want to remove them. For instance, my file
    server had dbus-daemon-launch-helper setuid root. I removed this crap
    as dbus has nothing to do on such a machine. Similarly I don't need
    fdmount to mount floppies. I might not use floppies often, and if I do,
    I know how to use sudo.

       $ find / -user root -perm -4000 -ls

  - last considerations to keep in mind is that machines which receive
    incoming connections from outside should never be able to go out, and
    should be isolated in their own LAN. It's not hard to do at all, and
    it massively limits the ability to bounce between systems and to steal
    information. It also makes firewall logs much more meaningful, provided
    they are stored on a support with limited access, of course :-)

Regards,
Willy

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Fri, Sep 30, 2011 at 04:50:37PM -0700, H. Peter Anvin wrote:
> 2. Create a new PGP/GPG key, and also generate a key revocation
>    certificate (but don't import it anywhere -- save it for the
>    future) for your new key.  In the near future we are considering
>    setting up an escrow service for key revocation certificates.
> 
>    I recommend using a 4096-bit RSA key.  Given how fast computers are
>    these days, there is no reason to use a shorter key.  DSA keys
>    should be considered obsolete; substantial weaknesses have been
>    found in DSA.
> 
>    $ gpg --gen-key
>    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke

I would recommend a physical access device for your new gpg key that you
create.  I've heard good things about this USB device:
	http://www.crypto-stick.org/
and am trying to have a bunch of them at the Kernel Summit this year to
hand out to people if they want one.

There are also lots of other smart-card form-factor devices that can be
used to store GPG keys.  Some places to purchase these can be found at
links from the above site.

thanks,

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Sat, Oct 01, 2011 at 09:35:33AM +0200, Willy Tarreau wrote:
> Hi Greg,
> 
> On Fri, Sep 30, 2011 at 04:59:24PM -0700, Greg KH wrote:
> > The compromise of kernel.org and related machines has made it clear that
> > some developers, at least, have had their systems penetrated.  As we
> > seek to secure our infrastructure, it is imperative that nobody falls
> > victim to the belief that it cannot happen to them.  We all need to
> > check our systems for intrusions.  Here are some helpful hints as
> > proposed by a number of developers on how to check to see if your Linux
> > machine might be infected with something:
> 
> I would like to add here a few controls I ran on firewall and system logs,
> that are easy to perform and which report few false positives :

<snip>

Thanks for this great list, it is much appreciated.

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[akwatts]

Greg, many thanks for providing these helpful hints for assessing 
system integrity.

On Fri, Sep 30, 2011 at 04:59:24PM -0700, Greg KH wrote:
> The compromise of kernel.org and related machines has made it clear that
> some developers, at least, have had their systems penetrated.  As we
> seek to secure our infrastructure, it is imperative that nobody falls
> victim to the belief that it cannot happen to them.  We all need to
> check our systems for intrusions.  Here are some helpful hints as
> proposed by a number of developers on how to check to see if your Linux
> machine might be infected with something:

I understand that git repos are protected from ex-post tampering by a
rolling sha-1 hash. However, is it possible that code submissions were
faked during the intrusion window and pulled by legitimate subsystem
or system managers?

The intrusion on kernel.org has been dated as potentially weeks
before 8/28 which means many tarballs (that common users rely on more
than git) were posted after that.

Can we confirm a few things?

a) do we know have a better estimate on the date of the initial breach?
b) is there any chance that the signing key (517D0F0E) was compromised?
c) can someone with verifiably clean code (i.e. not just downloads from
   kernel.org) post checksums (md5,sha1,rmd160) for official tarball
   releases since say 3/2011 (both full kernel and patches)?

Many thanks.

~ Andy

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Sat, Oct 01, 2011 at 09:17:51AM -0500, akwatts@ymail.com wrote:
> Greg, many thanks for providing these helpful hints for assessing 
> system integrity.
> 
> On Fri, Sep 30, 2011 at 04:59:24PM -0700, Greg KH wrote:
> > The compromise of kernel.org and related machines has made it clear that
> > some developers, at least, have had their systems penetrated.  As we
> > seek to secure our infrastructure, it is imperative that nobody falls
> > victim to the belief that it cannot happen to them.  We all need to
> > check our systems for intrusions.  Here are some helpful hints as
> > proposed by a number of developers on how to check to see if your Linux
> > machine might be infected with something:
> 
> I understand that git repos are protected from ex-post tampering by a
> rolling sha-1 hash. However, is it possible that code submissions were
> faked during the intrusion window and pulled by legitimate subsystem
> or system managers?
> 
> The intrusion on kernel.org has been dated as potentially weeks
> before 8/28 which means many tarballs (that common users rely on more
> than git) were posted after that.
> 
> Can we confirm a few things?

At this time, we are unable to discuss the events that took place due
to an ongoing investigation into the matter.  After that is complete, I
will be working to provide a report of what happened, but that will take
some time.

When www.kernel.org and git.kernel.org come back up, the kernels on them
will have been checked to be verified to be correct.  Everyone involved
is working as hard as they can to make that happen as soon as is
possible.

> c) can someone with verifiably clean code (i.e. not just downloads from
>    kernel.org) post checksums (md5,sha1,rmd160) for official tarball
>    releases since say 3/2011 (both full kernel and patches)?

You can do this today yourself from Linus's git tree if you want to,
it's very easy to script.  Just watch out for the fact that gzip puts
dates into the header, so you need to check the .tar file, not the
compressed ones.

thanks for your patience,

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[Andy]

On Sat, Oct 01, 2011 at 07:28:48AM -0700, Greg KH wrote:
> When www.kernel.org and git.kernel.org come back up, the kernels on them
> will have been checked to be verified to be correct.  Everyone involved
> is working as hard as they can to make that happen as soon as is
> possible.

Thank you for quick reply and I appreciate all the post-mortem work
that is surely being carried out by all parties involved.

~ Andy

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

On Sat, Oct 01, 2011 at 07:28:48AM -0700, Greg KH wrote:
> On Sat, Oct 01, 2011 at 09:17:51AM -0500, akwatts@ymail.com wrote:
> > Greg, many thanks for providing these helpful hints for assessing 
> > system integrity.
> > 
> > On Fri, Sep 30, 2011 at 04:59:24PM -0700, Greg KH wrote:
> > > The compromise of kernel.org and related machines has made it clear that
> > > some developers, at least, have had their systems penetrated.  As we
> > > seek to secure our infrastructure, it is imperative that nobody falls
> > > victim to the belief that it cannot happen to them.  We all need to
> > > check our systems for intrusions.  Here are some helpful hints as
> > > proposed by a number of developers on how to check to see if your Linux
> > > machine might be infected with something:
> > 
> > I understand that git repos are protected from ex-post tampering by a
> > rolling sha-1 hash. However, is it possible that code submissions were
> > faked during the intrusion window and pulled by legitimate subsystem
> > or system managers?
> > 
> > The intrusion on kernel.org has been dated as potentially weeks
> > before 8/28 which means many tarballs (that common users rely on more
> > than git) were posted after that.
> > 
> > Can we confirm a few things?
> 
> At this time, we are unable to discuss the events that took place due
> to an ongoing investigation into the matter.  After that is complete, I
> will be working to provide a report of what happened, but that will take
> some time.
> 
> When www.kernel.org and git.kernel.org come back up, the kernels on them
> will have been checked to be verified to be correct.  Everyone involved
> is working as hard as they can to make that happen as soon as is
> possible.
> 
> > c) can someone with verifiably clean code (i.e. not just downloads from
> >    kernel.org) post checksums (md5,sha1,rmd160) for official tarball
> >    releases since say 3/2011 (both full kernel and patches)?
> 
> You can do this today yourself from Linus's git tree if you want to,
> it's very easy to script.  Just watch out for the fact that gzip puts
> dates into the header, so you need to check the .tar file, not the
> compressed ones.

Here's what I've done on my side on the tags I had :

  for i in $(git tag|grep ^v[23]|grep -v pre|grep -v rc); do
    echo -n "${i#v} "
    git archive --format tar --prefix linux-${i#v}/ $i | md5sum
  done

On the 2.4 repo, here are the md5 outputs :

  2.4.32 f61801c23a59377de9dbae622ffc4ea7  -
  2.4.33 4cf5ea87123b8683628545288e4250ec  -
  2.4.34 46350ec55391a9d2a44507d130a98462  -
  2.4.35 373ea382a7437a2a431e2aa4eb1c6306  -
  2.4.35.1 cf6632ac5f580a53909c01e600e2d8a0  -
  2.4.35.2 de26727b0a6123a01f1de178bc403960  -
  2.4.35.3 2e7493ebd8df7414cdfbbbe77b4ab63e  -
  2.4.35.4 396a157f51cc1e62a6764a8ad98c98d1  -
  2.4.35.5 433b3b235d54d8891033581459479dd0  -
  2.4.36 13770787fe7fa2c99824eee5ad7fc43d  -
  2.4.36.1 4d8bf038ba2be8f9f5ceda3dd569c472  -
  2.4.36.2 5683ba1cbc87147b7b823ba21d583aa2  -
  2.4.36.3 cbf7e13926cfe33aefc795bd8c044a92  -
  2.4.36.4 6e3c826a3bae477281e43e9cf6824fe6  -
  2.4.36.5 6f390c5c278b3e858a0473e45da70b2c  -
  2.4.36.6 766a950b86c7933c500aeb1691734fa0  -
  2.4.36.7 9aa935e267aebd4048127041c1e86f99  -
  2.4.36.8 0978df7d54780fabc688e12dc393e7a0  -
  2.4.37 ed4580734549cd767429ab709dd43911  -
  2.4.37.1 d22450e8b0f59a5445f868eb44cf681f  -
  2.4.37.10 6561ab83d5f408d2a907e3b3e3387128  -
  2.4.37.11 2d25eeb6339bfce740aacc7d55851141  -
  2.4.37.2 71470ea080b1d889b9aa27295ffa202d  -
  2.4.37.3 5ff755c12bd388920a316e93731b6457  -
  2.4.37.4 474201a6b745be29167584771e175eca  -
  2.4.37.5 6f101339fa78eb675f429e48f7959e83  -
  2.4.37.6 96c2a83d58b4af8dbe97950ae94bd01c  -
  2.4.37.7 ec133f356ba67bcd4108e1a00ede4e74  -
  2.4.37.8 8f7c3d831693919488810177fb399ae8  -
  2.4.37.9 e9f3b73a84dfb6bfd7fe7fd30e8892e9  -

Those md5 should be compared with the ones from the uncompressed
archives :

  for i in linux-[23].[0-9]*.tar.bz2; do
    echo -n "$i ";bzcat $i|md5sum
  done

  linux-2.4.37.11.tar.bz2 2d25eeb6339bfce740aacc7d55851141  -

Result: it's correct. With a bit of scripting, it's easy to match
tags signatures with tarballs'.

The same must be done on tar.gz versions too. While typing this mail,
I had the script running on 2.6 tags and here's what I have at this
point (git archive is amazingly fast!) :

  2.6.11 b390eb0350b4f953a53c16dd5c28810e  -
  2.6.12 2aeacc403998f8868a14c6bfde2355cb  -
  2.6.13 f00810aacdbdcbe313b266172595b81c  -
  2.6.14 ff5ad004e49d7ec7adc8b0dd5161736b  -
  2.6.15 183e68cec3f221e4240b8acb0ac2b27d  -
  2.6.16 3437d1e2944a86ca2b31d9b34664df0b  -
  2.6.17 fbca10e30d7df32e87677f39d470b911  -
  2.6.18 4ff78d8a1b1a5fc93760f3d2e49cb709  -
  2.6.19 dbbf2847a6c76aa730bada4018ea4529  -
  2.6.20 3905ab26c24c974e97eee4628ba1f2eb  -
  2.6.20.1 c550ea5cee783951006450caa3dd3f95  -
  2.6.20.10 3865227516b1ed115dcf52eda4ff1ad8  -
  2.6.20.11 235e4c9dda5c423ac3ccd3aee7587553  -
  2.6.20.12 8d9cc27403c29355549998b7966d6350  -
  2.6.20.13 7331349a0e0fe5dbd230fb10900846f4  -
  2.6.20.14 8e7be87759f3ead0852137e366c34a90  -
  2.6.20.15 7bad3d284c2cbbaed0d2338f81e76859  -
  2.6.20.16 25a1013fabd489d302f71bf3cb1837b3  -
  2.6.20.17 5259b132a710eacc1e7489129f3b9e0f  -
  2.6.20.18 4af3439c081f86b68a30d0bd447179c3  -
  2.6.20.19 8bee08600da3f46bce0d2f15b1e3b68e  -
  2.6.20.2 61056db1f9194d0a153ece9572200b4a  -
  2.6.20.20 eb1b62690aa859f6d1deb70695e253a0  -
  2.6.20.21 f85b1a1337f825832d1b39d1c62f457f  -
  2.6.20.3 32820a679e81cdeb454f54d0994cf968  -
  2.6.20.4 dda6d62ecfcfd5d0f2d7ae9bd1107b6b  -
  2.6.20.5 c39381da208d5c15a2710673df5654fc  -
  2.6.20.6 60065c3db7d5ebe97cef36022933ca0d  -
  2.6.20.7 4352dedea3918d2c7d3a059bb00aa580  -
  2.6.20.8 b26f5458b175e3b935586c433aa82c8d  -
  2.6.20.9 12bf096a9ec27317a7fd0bf5241aa86d  -
  2.6.21 53957189a9f2a382973c1063bd2e8954  -
  2.6.21.1 c081d29d0c6ff1b61fd962b8259ecbc6  -
  2.6.21.2 78d892b513b1b323ad12e3d3c69f6dbb  -
  2.6.21.3 26b27b1aacaac870c94c3ce14155489c  -
  2.6.21.4 562dbfe628d7f4ec5be02f2eee444209  -
  2.6.21.5 4c778ee298cba1ba82d8f8ec00959f3d  -
  2.6.21.6 3fc9cbc5f1eabdb79f0f819785aa79ee  -
  2.6.21.7 d4efe4b192ca2be608b75a881ebca902  -
  2.6.22 1db7e438e6a88f0d7588226a75d109c2  -
  2.6.22.1 93e4955063c604799affa171cb6370d4  -
  2.6.22.10 2dc8fd7f16668e1997a74a1e731febe6  -
  2.6.22.11 57eb4df5f3863be6c6be405eb8a97c1a  -
  2.6.22.12 055c7b258abb9489dbced86537c7dc4e  -
  2.6.22.13 c1f411391548652149ea78afd7ffd026  -
  2.6.22.14 ee15acfef4c0e9b787816546129c34a8  -
  2.6.22.15 159067c422109e1b56e43fdf34e049f7  -
  2.6.22.16 cf84f4aca3f11062968b5ce2351560c3  -
  2.6.22.17 18a6b5c1759d2ed3d2552767d76329a0  -
  2.6.22.18 b64d9b8f3c050692538ec941cc6ffd2c  -
  2.6.22.19 5d5f55c4a794af96dfb7de2114755bba  -
  2.6.22.2 5af3437e6ff97f9920d227681f1c7b5e  -
  2.6.22.3 65e5a5d73e732ef3657554b2eeeb3547  -
  2.6.22.4 d2294a1e23ef416c0b03cfb84acccd3f  -
  2.6.22.5 34bfb927e95b7645ecace1becf492b09  -
  2.6.22.6 a610d656962ebfbd46efd96ce0a96c66  -
  2.6.22.7 d89f77ec176b0eab0be04ecdd06c1a2f  -
  2.6.22.8 3b49a858cd506f320fa24adcec47c8ab  -
  2.6.22.9 db2827199bfa42595a25bdad5e6fe500  -
  2.6.23 534de4be852986f77cf75b2c27b797b3  -
  2.6.24 37991d8ae19d709b63c95fb84c50ac30  -
  2.6.25 0772dbf15ef73fe5cb64c91101896b7a  -
  2.6.25.1 ca288f8d0a47a31a2007da996212dace  -
  2.6.25.10 29fbcbf3fa504b000e6b405c681e91eb  -
  2.6.25.11 225c43654b864c303822385572e8df9d  -
  2.6.25.12 f5d46c6ae6d2a97f8d54610d8a71665b  -
  2.6.25.13 d2affb4524db60f4e0c8c79a01fc565b  -
  2.6.25.14 39380a57e0d2826acc72e16e0d0bbe86  -
  2.6.25.15 32c56b46350368ca97f0afc4dc291e4d  -
  2.6.25.16 9701b00fedc1d674db536adc5e5ddf11  -
  2.6.25.17 47b63e5d2f59ea4f945fc954ef4aac29  -
  2.6.25.18 a26142b7c3b02860bc1bb2eddaf621e3  -
  2.6.25.19 78273a08ffe44e3a85a0574e7d67f367  -
  2.6.25.2 5199cfe55c13162661ec4035272e072d  -
  2.6.25.20 6eea4d0acd22b88c124ce2dfe70a716a  -
  2.6.25.3 5857b5bb21fe8d41460e89b87b9f5362  -
  2.6.25.4 e64c0ae28293e0c578a029af170150d2  -
  2.6.25.5 828cad924870acb9643bf4bb0f72cc92  -
  2.6.25.6 6e0ee8c95c9aa2b619dd9159c1eab57d  -
  2.6.25.7 9ccdda12b747a122a94ac30e735ba9f9  -
  2.6.25.8 b1adac6690deea86340d5e18fd7bee7c  -
  2.6.25.9 b737d23e536e7f9bd93a5888656c6a87  -
  2.6.26 fc8cde1368ab6ed0e3f04008b29bea4d  -
  2.6.27 f4a2389af9ab16b0625578217934e2f0  -
  2.6.27.1 b02d388a1b5179fd40139bdc6d5a2ccd  -
  2.6.27.10 18abcd2d7d157c1cb02bc77f9c2834e7  -
  2.6.27.11 38c7b9727f34961d25471cf3962079fd  -
  2.6.27.12 54f8917ddd5b8c0b89e58aa348a725f0  -
  2.6.27.13 18dfed96ccf2ca4874953d5a2618ab63  -
  2.6.27.14 b8721dbdace184d588d68dc5639feb9c  -
  2.6.27.15 c7e39c082d49e20cf5da354e3e603214  -
  2.6.27.16 81462897e5ddab2c09f79f9c58c6bacf  -
  2.6.27.17 5a03443dcef39fc7b6afa3d7ab9e22b4  -
  2.6.27.18 8e272f65bf0c7dc73c57d85dc6c75b9f  -
  2.6.27.19 61e60b5c2fe91f28da019a078be8d0a5  -
  2.6.27.2 104577a9cb43ee17832e6079a05bb37d  -
  2.6.27.20 8324c79cc242afdfe86f1e5964e49d60  -
  2.6.27.21 13a0e7ca645dcc462a2c0f4e265a6760  -
  2.6.27.22 7f76aff66928dab42db7fd9c963b0813  -
  2.6.27.23 399cf04ceb5f05eddea8a9782cc2ddab  -
  2.6.27.24 2cb77153d209a55367edc8398f4afa88  -
  2.6.27.25 bb963116a132b885f4902ddc1e561920  -
  2.6.27.26 0bf3c35f3807bdd95a3e74d691392afd  -
  2.6.27.27 3e4f73295dc177201ab546bcb360feae  -
  2.6.27.28 e52c78805e8f44af814f9e76613e04b2  -
  2.6.27.29 5a7de732a819d219f51fe5b47f645555  -
  2.6.27.3 88b3887f45666600820778d4d10d4d86  -
  2.6.27.30 a19b497d70fe55519e1fc158ce5afe0d  -
  2.6.27.31 f5bd4a54000bbc19b319cd1c084c0b1a  -
  2.6.27.32 7321d15dcab7a704bf4bb78a0bc0c599  -
  2.6.27.33 55fcebf49f18a06e24468d5b4b70dfd9  -
  2.6.27.34 7d8eb3d81e947465a6c0deb52839b20b  -
  2.6.27.35 1289c724be385e99e89593ea39835ad9  -
  2.6.27.36 ee2a5457dcb337956bc03059fc92c2a1  -
  2.6.27.37 e90869665b6e4860828c0f7097aaa513  -
  2.6.27.38 763dbfd6558ce5dee3ae8ce720b2645c  -
  2.6.27.39 dc579c8445954eb512977b28224dfef9  -
  2.6.27.4 dbb8b8b58962acf4945a5d73810330d6  -
  2.6.27.40 a75c56fb79c601fa6a8ee753672895ef  -
  2.6.27.41 832c145c0ad862d038b41c6a09e19e6f  -
  2.6.27.42 5df04b71553553d1e5833c65008425d5  -
  2.6.27.43 50b70a5f28747b070bdfd0bcc7f9529b  -
  2.6.27.44 07f9c9509becfdf6ddef4f142a2b87fd  -
  2.6.27.45 5df8e25fcaaf9ec0b108c68d31c1f23a  -
  2.6.27.46 feb0c66e8af4e3c73bb7675ad99633cb  -
  2.6.27.47 a10aedc65ec24f5b9f5e7d2534adf94e  -
  2.6.27.48 dab808dedf4eb7e1425cdb0b30a4c8cf  -
  2.6.27.49 d0ec0912960ab79e90d228da7fac1d67  -
  2.6.27.5 99b5eb960d4709d8eab162696d7601dd  -
  2.6.27.50 ce3e327c7291fe271340eaf2904a4347  -
  2.6.27.51 3256ec86d0249f6f0bf967718fd35363  -
  2.6.27.52 ed87ed7d7fce749a3faf845c85880ef9  -
  2.6.27.53 108d6b3f2c723bc4360e3bbbb2474aec  -
  2.6.27.54 cc203656605a40fca27f90e993952788  -
  2.6.27.55 28b6bb904578f3bbc3dafe22b0f3512a  -
  2.6.27.56 d135df3b77fe7c83ecc369139719085a  -
  2.6.27.57 8a6cc185e7c91835b12c85969a3f00f3  -
  2.6.27.58 b9f88fc59a5b7dede53249eb1cf056d5  -
  2.6.27.59 b13ed9fb91f415f16549da6b05cf0a55  -
  2.6.27.6 921927e2cce7f3e59c4f76d54c77ffcb  -
  2.6.27.7 da79852b3b31b665ddac1eaff1712747  -
  2.6.27.8 10b609f0af0a4fcf0ed18e2d076d8310  -
  2.6.27.9 b62bfd7ba8a13833440abb458267c8cd  -
  2.6.28 e97b8459593e20a7bd2d75ecce4cd9a1  -
  2.6.29 8354f1b9f6364047278aaa9a160e6010  -
  2.6.29.1 3378af02af06b10b3725a7f90a1e2832  -
  2.6.29.2 df3f8999068ca47425826f97643a9b01  -
  2.6.29.3 0c32afeb514f2909950c10704ea1c251  -
  2.6.29.4 3510ca1d830c8b9fcef92c258d0a4762  -
  2.6.29.5 cef8e5a3bbf183e7ad3281b1f3bfe657  -
  2.6.29.6 3d9def1cc78eac6271b54194434695e3  -
  2.6.30 a1d93463120021669925776fcf94592e  -
  2.6.30.1 1f57a5f8a65bd38e7b9c2f2c1ae32f66  -
  2.6.30.2 bbc68779259558afca403ca041b49073  -
  2.6.30.3 6a5963823ecfc432f36827d5c17b9cd0  -
  2.6.30.4 9a3533d3a716913fdf7f8b73f1beae45  -
  2.6.30.5 b446af3c919a4cf65008b61f75e88cd6  -
  2.6.30.6 4d87e17f3b3448ce7e69afc9debf0efd  -
  2.6.30.7 e5a18192355fc18831f83ad8338378f9  -
  2.6.30.8 f6c70ebeaaa1e0f23cf4310bba9ac827  -
  2.6.30.9 327a5876f9884ac4e2dd79b642790b4f  -
  2.6.31 f3fa1f5cb17d43bdea3cb0b214ee16c4  -
  2.6.31.1 0697e50b0515da0c94700a56acaf84f1  -
  2.6.31.2 4e5ee234f4d1ce8a2a97e81d1c3e5e3e  -
  2.6.31.3 f686666a2218afd13f2c6bc794919615  -
  2.6.31.4 e2e84fc3cea9293517698f2af02e3698  -
  2.6.31.5 a1518ae179af94eb840024655ed4471a  -
  2.6.31.6 660348915031cc50ede9b6ae2028bf52  -
  2.6.32 a0e27bc0c5a53a1a895c76d88a5acc1a  -
  2.6.32.1 5be63bd57f8672db69198a8ec7a04637  -
  2.6.32.10 32aa41fbc18fbe1cf1e8535e677c13a4  -
  2.6.32.11 212f747ca5999b395bcc03799399b8ad  -
  2.6.32.12 b73836b409909ba691e442a851221bab  -
  2.6.32.13 1f72687582dd1bf5aa7d9a1b01ac11f5  -
  2.6.32.14 8af1c02cefc69f902008b6d16e2a5f19  -
  2.6.32.15 c86b467e8649d5b782e5c85d7bada2c3  -
  2.6.32.16 34f9d86da519c3ac868bb6b9c0edf5fd  -
  2.6.32.17 41fa851916eb3e208eb2d07d9a2edc20  -
  2.6.32.18 e93ea8c463c761b6733ca9550de9d28d  -
  2.6.32.19 baa03d63e6eb52c870ef5f4dee6bff81  -
  2.6.32.2 cbd1bab8027a01ec42c28278879a7209  -
  2.6.32.20 9b4b3ccbdb161284db7c50d8fa7a9cc4  -
  2.6.32.21 4e2d3f2ca147c1d18a0c042bb39e8296  -
  2.6.32.22 c1bbd1b7be8f5bc5b8ec845ba4cfa6d6  -
  2.6.32.23 7706a8fa891540f5eaaf0b504505473d  -
  2.6.32.24 e19d2bef8b40fe3870bb0b8e9bfa2f4b  -
  2.6.32.25 1e8ea8d88db9ea220746c317c891c6d7  -
  2.6.32.26 21db42cb4175753d6b702138b2d16035  -
  2.6.32.27 f3b4b1aefc240a75b84ce8c83c1d8203  -
  2.6.32.28 c63f9b5a3344f866620f6ae10be15881  -
  2.6.32.29 a6546c1fad45fa336885860d31f89b9e  -
  2.6.32.3 8dd90672223a82d8cbfa9bf0ecf6c70b  -
  2.6.32.30 8b3e0d9612b61cdbf4a9a01566010fa4  -
  2.6.32.31 5dcf526758804fa382f231073a442ebe  -
  2.6.32.32 a3fd490344081ddc863c85e066c26de4  -
  2.6.32.33 a22b0dd689764e1aa2abcbc4f3f38899  -
  2.6.32.34 7c596527748f917b0df22321b83c9eb9  -
  2.6.32.35 31b9c268a72f183b37a609ce1688ed33  -
  2.6.32.36 21d809b12592e91d100f40ee9c415e94  -
  2.6.32.37 88572d1d95f9417a93db60a954f3ce9c  -
  2.6.32.38 75e4d93ea9c57c28acd169902c70ffe7  -
  2.6.32.39 6d266224d3ff0d136b336228fe108f3a  -
  2.6.32.4 2cf5b76b3aa71790215b45afcfa8906e  -
  2.6.32.40 27cd2ab5f45c83effbca8f894b9bf9a4  -
  2.6.32.41 3da56d911ae16e1d9d04d27e97140094  -
  2.6.32.42 74189193fa0b44a74bfe31de2934396f  -
  2.6.32.43 702e1151878c159021bfed717483d078  -
  2.6.32.5 cc137ff7c3f9cd033bab9ddadfa09b9b  -
  2.6.32.6 d1561434aa81622f6b17b72c8e00c226  -
  2.6.32.7 c0fcd24b3b3783afefda8f77b0c95a03  -
  2.6.32.8 2e09e2ecd521b5fb43cc577e88e98356  -
  2.6.32.9 9e1ddce5bf49fbf740fe4967990b3f83  -
  2.6.33 6fabba8f967b90f85e6ececa26531ddd  -
  2.6.33.1 c604a96b1006c24da58237b9e55195a9  -
  2.6.33.2 6453571f38b4dfaa602f7585a7616c48  -
  2.6.33.3 a940c369b6d48fd3aea62d86d3a3b324  -


Checking the tarballs takes substantially longer on bz2 files,
and requires that we download them, unless the check is run on
kernel.org disks.

Regards,
Willy

Re: kernel.org status: hints on how to check your machine for intrusion

[Andy]

On Sat, Oct 01, 2011 at 06:56:59PM +0200, Willy Tarreau wrote:
> Result: it's correct. With a bit of scripting, it's easy to match
> tags signatures with tarballs'.

I must be doing something wrong. I only have the 2.6 git repo (so my tags
don't drill down to 2.6.x.y just 2.6.x) but my experiement isn't giving
the results I expected.

[Cloned repo]
$ git archive --format=tar --prefix linux-2.6.39/ v2.6.39 | md5sum
482f8bd941def0548a95f34e2d290dfd  -

[Downloaded from kernel.org]
$ bzcat linux-2.6.39.tar.bz2 | md5sum
833d224ee42ddc1e7c2d256368b5d7b3  -

~ Andy

Re: kernel.org status: hints on how to check your machine for intrusion

[Andreas Schwab]

Andy <akwatts@ymail.com> writes:

> I must be doing something wrong. I only have the 2.6 git repo (so my tags
> don't drill down to 2.6.x.y just 2.6.x) but my experiement isn't giving
> the results I expected.
>
> [Cloned repo]
> $ git archive --format=tar --prefix linux-2.6.39/ v2.6.39 | md5sum
> 482f8bd941def0548a95f34e2d290dfd  -

Try setting tar.umask to 022 (default is 002).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

On Sat, Oct 01, 2011 at 12:19:16PM -0500, Andy wrote:
> On Sat, Oct 01, 2011 at 06:56:59PM +0200, Willy Tarreau wrote:
> > Result: it's correct. With a bit of scripting, it's easy to match
> > tags signatures with tarballs'.
> 
> I must be doing something wrong. I only have the 2.6 git repo (so my tags
> don't drill down to 2.6.x.y just 2.6.x) but my experiement isn't giving
> the results I expected.
> 
> [Cloned repo]
> $ git archive --format=tar --prefix linux-2.6.39/ v2.6.39 | md5sum
> 482f8bd941def0548a95f34e2d290dfd  -

Indeed I have the same here.

> [Downloaded from kernel.org]
> $ bzcat linux-2.6.39.tar.bz2 | md5sum
> 833d224ee42ddc1e7c2d256368b5d7b3  -

An archive I found from this mirror indeed gave me the same md5 as
yours :

   http://mirror.anl.gov/pub/linux/kernel/v2.6/

OK, found! 2.6 kernels are archived with tar.umask = 022 while I
did not have this config option here. If I fix the umask, I get the
same md5 as in the tarball :

  $ git config tar.umask 022
  $ git archive --format tar --prefix linux-2.6.39/ v2.6.39 | md5sum

So I can redo all the md5 sigs now :-/

Willy

Re: kernel.org status: hints on how to check your machine for intrusion

[Steven Rostedt]

On Sat, Oct 01, 2011 at 09:35:33AM +0200, Willy Tarreau wrote:
> 
>   - last considerations to keep in mind is that machines which receive
>     incoming connections from outside should never be able to go out, and
>     should be isolated in their own LAN. It's not hard to do at all, and
>     it massively limits the ability to bounce between systems and to steal
>     information. It also makes firewall logs much more meaningful, provided
>     they are stored on a support with limited access, of course :-)

For my machine that is connected to the outside world, I have a script
that runs every night that checks for attacks. As bots constantly look
for port 22 and 80, they find my machine without issue. When my script
detects a bunch of ssh login attempts that fail, it will add that ip
address to the iptables DROP chain:

# iptables -L -n | grep DROP | wc -l
2656

I've picked up quite a few ;)

This script only runs and scans once at night. Probably better to have
it run more often.

If any one is interested in this simple script, I can send it to them.
I'd have to audit it to make sure that it doesn't expose anything else
that may be of security to me (other machine IPs that I don't want
public, etc).

-- Steve

Re: kernel.org status: hints on how to check your machine for intrusion

[David Miller]

From: Steven Rostedt <rostedt@goodmis.org>
Date: Sat, 1 Oct 2011 14:06:41 -0400

> For my machine that is connected to the outside world, I have a script
> that runs every night that checks for attacks. As bots constantly look
> for port 22 and 80, they find my machine without issue. When my script
> detects a bunch of ssh login attempts that fail, it will add that ip
> address to the iptables DROP chain:

By running sshd on a different port, you'll avoid the login attempts
as well as the overhead of the successful connection attempts.

I haven't allowed sshd to run on port 22 in more than 10 years.

Re: kernel.org status: hints on how to check your machine for intrusion

[Steven Rostedt]

On Sat, 2011-10-01 at 14:13 -0400, David Miller wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Sat, 1 Oct 2011 14:06:41 -0400
> 
> > For my machine that is connected to the outside world, I have a script
> > that runs every night that checks for attacks. As bots constantly look
> > for port 22 and 80, they find my machine without issue. When my script
> > detects a bunch of ssh login attempts that fail, it will add that ip
> > address to the iptables DROP chain:
> 
> By running sshd on a different port, you'll avoid the login attempts
> as well as the overhead of the successful connection attempts.
> 
> I haven't allowed sshd to run on port 22 in more than 10 years.

I use to do that a long time ago, but I ran into issues because of it.
Can't remember the exact problem. Maybe it was places I went to that did
not allow outgoing connections to non official ports. Whatever it was,
it was annoying enough to put sshd back to 22.

I probably can go back to a non 22 port without much issue. I have added
a bunch of personal checks to this box that gives a report every day. I
may add more (from what was posted in this thread already). I also have
logwatch and rkhunter running, and just added chkrootkit now.

But moving the ssh port again may be a good idea. But I like stressing
your net filtering code ;)

-- Steve

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

On Sat, Oct 01, 2011 at 02:29:22PM -0400, Steven Rostedt wrote:
> On Sat, 2011-10-01 at 14:13 -0400, David Miller wrote:
> > From: Steven Rostedt <rostedt@goodmis.org>
> > Date: Sat, 1 Oct 2011 14:06:41 -0400
> > 
> > > For my machine that is connected to the outside world, I have a script
> > > that runs every night that checks for attacks. As bots constantly look
> > > for port 22 and 80, they find my machine without issue. When my script
> > > detects a bunch of ssh login attempts that fail, it will add that ip
> > > address to the iptables DROP chain:
> > 
> > By running sshd on a different port, you'll avoid the login attempts
> > as well as the overhead of the successful connection attempts.
> > 
> > I haven't allowed sshd to run on port 22 in more than 10 years.
> 
> I use to do that a long time ago, but I ran into issues because of it.
> Can't remember the exact problem. Maybe it was places I went to that did
> not allow outgoing connections to non official ports. Whatever it was,
> it was annoying enough to put sshd back to 22.

443 is pretty nice for connecting from unexpected places ;-)

> I probably can go back to a non 22 port without much issue. I have added
> a bunch of personal checks to this box that gives a report every day. I
> may add more (from what was posted in this thread already). I also have
> logwatch and rkhunter running, and just added chkrootkit now.
> 
> But moving the ssh port again may be a good idea. But I like stressing
> your net filtering code ;)

BTW ipset is particularly suited for this.

Regards,
Willy

Re: kernel.org status: hints on how to check your machine for intrusion

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

OK, I decided to attach the perl script anyway. It is very crude, and
really needs to be cleaned up for generic use.

I copy this file into /etc/cron.daily/01iptable-update and let the cron
daemon run it. I get nice little reports from cron when something is
added, like:

/etc/cron.daily/01iptables-update:
adding 8.25.218.88 to iptables blocked list
adding 116.125.124.20 to iptables blocked list
adding 38.99.131.171 to iptables blocked list

I officially announce that this file is being released under the GPLv2
license. If you want to fix it up. Feel free, but please send me a
copy ;)

Note, this was written for a Debian system. It reads
the /var/log/auth.log file. Your system may require a different read,
and maybe even different regex parsing.

-- Steve


[-- Attachment #2: iptables-examine-logs.pl --]
[-- Type: application/x-perl, Size: 3031 bytes --]

Re: kernel.org status: hints on how to check your machine for intrusion

[Andy]

On Sat, Oct 01, 2011 at 07:54:56PM +0200, Willy Tarreau wrote:
>   $ git config tar.umask 022

Andreas/Willy:

It was indeed umask which was skewing the results. Thanks.

Now, I'll wait for Willy's hashes since I can't drill down on
Linus' 2.6 tree beyond 2.6.x.

~ Andy

Re: kernel.org status: hints on how to check your machine for intrusion

[Steven Rostedt]

On Sat, 2011-10-01 at 14:40 -0400, Steven Rostedt wrote:
> OK, I decided to attach the perl script anyway. It is very crude, and
> really needs to be cleaned up for generic use.
> 

I've just been pointed to:

http://www.fail2ban.org/wiki/index.php/Main_Page

This looks like something similar.

You see, the reason I posted this tool is because I was sure people will
point me to better ones that do the same thing (and more!)   ;)

-- Steve

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Sat, Oct 01, 2011 at 01:40:44PM -0500, Andy wrote:
> On Sat, Oct 01, 2011 at 07:54:56PM +0200, Willy Tarreau wrote:
> >   $ git config tar.umask 022
> 
> Andreas/Willy:
> 
> It was indeed umask which was skewing the results. Thanks.
> 
> Now, I'll wait for Willy's hashes since I can't drill down on
> Linus' 2.6 tree beyond 2.6.x.

OK I'm attaching two files, one computed with the initial 002 perms and
a second one with the new 022 perms. I don't precisely know when the perms
changed, hence the two files. I noticed that 2.6.25 was still 002, and that
2.6.32 was 022. In between I don't know. Note that I'm missing some tags
(at least 2.6.35.12 and a few 2.6.33.x and 2.6.34.x).

The file is formated to be easily used with "md5sum -c" that dirty way
(once hashes are split/joined at the location where the umask changed) :

  cd /path/to/mirror/2.6
  cp linux-*.tar.gz /tmp
  cd /tmp
  gunzip linux-*.tar.gz
  md5sum -c expected-hashes.md5

It would be nice if someone with an access to a mirror could check the
perms of *every* tarball so that we can establish the definitive list
of signatures. I'm pretty sure the umask history is not linear. For
instance, I'm pretty sure I did not change the umask in my config when
releasing 2.6.27.x kernels and it seems like Greg did not do this either
so we have 2.6.27 022 and 2.6.27.x 002. Something like this might do it
(untested) :

  for i in linux-*.tar.gz; do
    set -- $(tar tvf $i|head -1)
    [ "$1" == "drwxrwxr-x" ] && echo "$i 002" || echo "$i 022"
  done

Hoping this helps a bit.

Willy


[-- Attachment #2: expected-hashes-002.md5 --]
[-- Type: text/plain, Size: 11519 bytes --]

b390eb0350b4f953a53c16dd5c28810e  linux-2.6.11.tar
2aeacc403998f8868a14c6bfde2355cb  linux-2.6.12.tar
f00810aacdbdcbe313b266172595b81c  linux-2.6.13.tar
ff5ad004e49d7ec7adc8b0dd5161736b  linux-2.6.14.tar
183e68cec3f221e4240b8acb0ac2b27d  linux-2.6.15.tar
3437d1e2944a86ca2b31d9b34664df0b  linux-2.6.16.tar
fbca10e30d7df32e87677f39d470b911  linux-2.6.17.tar
4ff78d8a1b1a5fc93760f3d2e49cb709  linux-2.6.18.tar
dbbf2847a6c76aa730bada4018ea4529  linux-2.6.19.tar
3905ab26c24c974e97eee4628ba1f2eb  linux-2.6.20.tar
c550ea5cee783951006450caa3dd3f95  linux-2.6.20.1.tar
3865227516b1ed115dcf52eda4ff1ad8  linux-2.6.20.10.tar
235e4c9dda5c423ac3ccd3aee7587553  linux-2.6.20.11.tar
8d9cc27403c29355549998b7966d6350  linux-2.6.20.12.tar
7331349a0e0fe5dbd230fb10900846f4  linux-2.6.20.13.tar
8e7be87759f3ead0852137e366c34a90  linux-2.6.20.14.tar
7bad3d284c2cbbaed0d2338f81e76859  linux-2.6.20.15.tar
25a1013fabd489d302f71bf3cb1837b3  linux-2.6.20.16.tar
5259b132a710eacc1e7489129f3b9e0f  linux-2.6.20.17.tar
4af3439c081f86b68a30d0bd447179c3  linux-2.6.20.18.tar
8bee08600da3f46bce0d2f15b1e3b68e  linux-2.6.20.19.tar
61056db1f9194d0a153ece9572200b4a  linux-2.6.20.2.tar
eb1b62690aa859f6d1deb70695e253a0  linux-2.6.20.20.tar
f85b1a1337f825832d1b39d1c62f457f  linux-2.6.20.21.tar
32820a679e81cdeb454f54d0994cf968  linux-2.6.20.3.tar
dda6d62ecfcfd5d0f2d7ae9bd1107b6b  linux-2.6.20.4.tar
c39381da208d5c15a2710673df5654fc  linux-2.6.20.5.tar
60065c3db7d5ebe97cef36022933ca0d  linux-2.6.20.6.tar
4352dedea3918d2c7d3a059bb00aa580  linux-2.6.20.7.tar
b26f5458b175e3b935586c433aa82c8d  linux-2.6.20.8.tar
12bf096a9ec27317a7fd0bf5241aa86d  linux-2.6.20.9.tar
53957189a9f2a382973c1063bd2e8954  linux-2.6.21.tar
c081d29d0c6ff1b61fd962b8259ecbc6  linux-2.6.21.1.tar
78d892b513b1b323ad12e3d3c69f6dbb  linux-2.6.21.2.tar
26b27b1aacaac870c94c3ce14155489c  linux-2.6.21.3.tar
562dbfe628d7f4ec5be02f2eee444209  linux-2.6.21.4.tar
4c778ee298cba1ba82d8f8ec00959f3d  linux-2.6.21.5.tar
3fc9cbc5f1eabdb79f0f819785aa79ee  linux-2.6.21.6.tar
d4efe4b192ca2be608b75a881ebca902  linux-2.6.21.7.tar
1db7e438e6a88f0d7588226a75d109c2  linux-2.6.22.tar
93e4955063c604799affa171cb6370d4  linux-2.6.22.1.tar
2dc8fd7f16668e1997a74a1e731febe6  linux-2.6.22.10.tar
57eb4df5f3863be6c6be405eb8a97c1a  linux-2.6.22.11.tar
055c7b258abb9489dbced86537c7dc4e  linux-2.6.22.12.tar
c1f411391548652149ea78afd7ffd026  linux-2.6.22.13.tar
ee15acfef4c0e9b787816546129c34a8  linux-2.6.22.14.tar
159067c422109e1b56e43fdf34e049f7  linux-2.6.22.15.tar
cf84f4aca3f11062968b5ce2351560c3  linux-2.6.22.16.tar
18a6b5c1759d2ed3d2552767d76329a0  linux-2.6.22.17.tar
b64d9b8f3c050692538ec941cc6ffd2c  linux-2.6.22.18.tar
5d5f55c4a794af96dfb7de2114755bba  linux-2.6.22.19.tar
5af3437e6ff97f9920d227681f1c7b5e  linux-2.6.22.2.tar
65e5a5d73e732ef3657554b2eeeb3547  linux-2.6.22.3.tar
d2294a1e23ef416c0b03cfb84acccd3f  linux-2.6.22.4.tar
34bfb927e95b7645ecace1becf492b09  linux-2.6.22.5.tar
a610d656962ebfbd46efd96ce0a96c66  linux-2.6.22.6.tar
d89f77ec176b0eab0be04ecdd06c1a2f  linux-2.6.22.7.tar
3b49a858cd506f320fa24adcec47c8ab  linux-2.6.22.8.tar
db2827199bfa42595a25bdad5e6fe500  linux-2.6.22.9.tar
534de4be852986f77cf75b2c27b797b3  linux-2.6.23.tar
37991d8ae19d709b63c95fb84c50ac30  linux-2.6.24.tar
0772dbf15ef73fe5cb64c91101896b7a  linux-2.6.25.tar
ca288f8d0a47a31a2007da996212dace  linux-2.6.25.1.tar
29fbcbf3fa504b000e6b405c681e91eb  linux-2.6.25.10.tar
225c43654b864c303822385572e8df9d  linux-2.6.25.11.tar
f5d46c6ae6d2a97f8d54610d8a71665b  linux-2.6.25.12.tar
d2affb4524db60f4e0c8c79a01fc565b  linux-2.6.25.13.tar
39380a57e0d2826acc72e16e0d0bbe86  linux-2.6.25.14.tar
32c56b46350368ca97f0afc4dc291e4d  linux-2.6.25.15.tar
9701b00fedc1d674db536adc5e5ddf11  linux-2.6.25.16.tar
47b63e5d2f59ea4f945fc954ef4aac29  linux-2.6.25.17.tar
a26142b7c3b02860bc1bb2eddaf621e3  linux-2.6.25.18.tar
78273a08ffe44e3a85a0574e7d67f367  linux-2.6.25.19.tar
5199cfe55c13162661ec4035272e072d  linux-2.6.25.2.tar
6eea4d0acd22b88c124ce2dfe70a716a  linux-2.6.25.20.tar
5857b5bb21fe8d41460e89b87b9f5362  linux-2.6.25.3.tar
e64c0ae28293e0c578a029af170150d2  linux-2.6.25.4.tar
828cad924870acb9643bf4bb0f72cc92  linux-2.6.25.5.tar
6e0ee8c95c9aa2b619dd9159c1eab57d  linux-2.6.25.6.tar
9ccdda12b747a122a94ac30e735ba9f9  linux-2.6.25.7.tar
b1adac6690deea86340d5e18fd7bee7c  linux-2.6.25.8.tar
b737d23e536e7f9bd93a5888656c6a87  linux-2.6.25.9.tar
fc8cde1368ab6ed0e3f04008b29bea4d  linux-2.6.26.tar
f4a2389af9ab16b0625578217934e2f0  linux-2.6.27.tar
b02d388a1b5179fd40139bdc6d5a2ccd  linux-2.6.27.1.tar
18abcd2d7d157c1cb02bc77f9c2834e7  linux-2.6.27.10.tar
38c7b9727f34961d25471cf3962079fd  linux-2.6.27.11.tar
54f8917ddd5b8c0b89e58aa348a725f0  linux-2.6.27.12.tar
18dfed96ccf2ca4874953d5a2618ab63  linux-2.6.27.13.tar
b8721dbdace184d588d68dc5639feb9c  linux-2.6.27.14.tar
c7e39c082d49e20cf5da354e3e603214  linux-2.6.27.15.tar
81462897e5ddab2c09f79f9c58c6bacf  linux-2.6.27.16.tar
5a03443dcef39fc7b6afa3d7ab9e22b4  linux-2.6.27.17.tar
8e272f65bf0c7dc73c57d85dc6c75b9f  linux-2.6.27.18.tar
61e60b5c2fe91f28da019a078be8d0a5  linux-2.6.27.19.tar
104577a9cb43ee17832e6079a05bb37d  linux-2.6.27.2.tar
8324c79cc242afdfe86f1e5964e49d60  linux-2.6.27.20.tar
13a0e7ca645dcc462a2c0f4e265a6760  linux-2.6.27.21.tar
7f76aff66928dab42db7fd9c963b0813  linux-2.6.27.22.tar
399cf04ceb5f05eddea8a9782cc2ddab  linux-2.6.27.23.tar
2cb77153d209a55367edc8398f4afa88  linux-2.6.27.24.tar
bb963116a132b885f4902ddc1e561920  linux-2.6.27.25.tar
0bf3c35f3807bdd95a3e74d691392afd  linux-2.6.27.26.tar
3e4f73295dc177201ab546bcb360feae  linux-2.6.27.27.tar
e52c78805e8f44af814f9e76613e04b2  linux-2.6.27.28.tar
5a7de732a819d219f51fe5b47f645555  linux-2.6.27.29.tar
88b3887f45666600820778d4d10d4d86  linux-2.6.27.3.tar
a19b497d70fe55519e1fc158ce5afe0d  linux-2.6.27.30.tar
f5bd4a54000bbc19b319cd1c084c0b1a  linux-2.6.27.31.tar
7321d15dcab7a704bf4bb78a0bc0c599  linux-2.6.27.32.tar
55fcebf49f18a06e24468d5b4b70dfd9  linux-2.6.27.33.tar
7d8eb3d81e947465a6c0deb52839b20b  linux-2.6.27.34.tar
1289c724be385e99e89593ea39835ad9  linux-2.6.27.35.tar
ee2a5457dcb337956bc03059fc92c2a1  linux-2.6.27.36.tar
e90869665b6e4860828c0f7097aaa513  linux-2.6.27.37.tar
763dbfd6558ce5dee3ae8ce720b2645c  linux-2.6.27.38.tar
dc579c8445954eb512977b28224dfef9  linux-2.6.27.39.tar
dbb8b8b58962acf4945a5d73810330d6  linux-2.6.27.4.tar
a75c56fb79c601fa6a8ee753672895ef  linux-2.6.27.40.tar
832c145c0ad862d038b41c6a09e19e6f  linux-2.6.27.41.tar
5df04b71553553d1e5833c65008425d5  linux-2.6.27.42.tar
50b70a5f28747b070bdfd0bcc7f9529b  linux-2.6.27.43.tar
07f9c9509becfdf6ddef4f142a2b87fd  linux-2.6.27.44.tar
5df8e25fcaaf9ec0b108c68d31c1f23a  linux-2.6.27.45.tar
feb0c66e8af4e3c73bb7675ad99633cb  linux-2.6.27.46.tar
a10aedc65ec24f5b9f5e7d2534adf94e  linux-2.6.27.47.tar
dab808dedf4eb7e1425cdb0b30a4c8cf  linux-2.6.27.48.tar
d0ec0912960ab79e90d228da7fac1d67  linux-2.6.27.49.tar
99b5eb960d4709d8eab162696d7601dd  linux-2.6.27.5.tar
ce3e327c7291fe271340eaf2904a4347  linux-2.6.27.50.tar
3256ec86d0249f6f0bf967718fd35363  linux-2.6.27.51.tar
ed87ed7d7fce749a3faf845c85880ef9  linux-2.6.27.52.tar
108d6b3f2c723bc4360e3bbbb2474aec  linux-2.6.27.53.tar
cc203656605a40fca27f90e993952788  linux-2.6.27.54.tar
28b6bb904578f3bbc3dafe22b0f3512a  linux-2.6.27.55.tar
d135df3b77fe7c83ecc369139719085a  linux-2.6.27.56.tar
8a6cc185e7c91835b12c85969a3f00f3  linux-2.6.27.57.tar
b9f88fc59a5b7dede53249eb1cf056d5  linux-2.6.27.58.tar
b13ed9fb91f415f16549da6b05cf0a55  linux-2.6.27.59.tar
921927e2cce7f3e59c4f76d54c77ffcb  linux-2.6.27.6.tar
da79852b3b31b665ddac1eaff1712747  linux-2.6.27.7.tar
10b609f0af0a4fcf0ed18e2d076d8310  linux-2.6.27.8.tar
b62bfd7ba8a13833440abb458267c8cd  linux-2.6.27.9.tar
e97b8459593e20a7bd2d75ecce4cd9a1  linux-2.6.28.tar
8354f1b9f6364047278aaa9a160e6010  linux-2.6.29.tar
3378af02af06b10b3725a7f90a1e2832  linux-2.6.29.1.tar
df3f8999068ca47425826f97643a9b01  linux-2.6.29.2.tar
0c32afeb514f2909950c10704ea1c251  linux-2.6.29.3.tar
3510ca1d830c8b9fcef92c258d0a4762  linux-2.6.29.4.tar
cef8e5a3bbf183e7ad3281b1f3bfe657  linux-2.6.29.5.tar
3d9def1cc78eac6271b54194434695e3  linux-2.6.29.6.tar
a1d93463120021669925776fcf94592e  linux-2.6.30.tar
1f57a5f8a65bd38e7b9c2f2c1ae32f66  linux-2.6.30.1.tar
bbc68779259558afca403ca041b49073  linux-2.6.30.2.tar
6a5963823ecfc432f36827d5c17b9cd0  linux-2.6.30.3.tar
9a3533d3a716913fdf7f8b73f1beae45  linux-2.6.30.4.tar
b446af3c919a4cf65008b61f75e88cd6  linux-2.6.30.5.tar
4d87e17f3b3448ce7e69afc9debf0efd  linux-2.6.30.6.tar
e5a18192355fc18831f83ad8338378f9  linux-2.6.30.7.tar
f6c70ebeaaa1e0f23cf4310bba9ac827  linux-2.6.30.8.tar
327a5876f9884ac4e2dd79b642790b4f  linux-2.6.30.9.tar
f3fa1f5cb17d43bdea3cb0b214ee16c4  linux-2.6.31.tar
0697e50b0515da0c94700a56acaf84f1  linux-2.6.31.1.tar
4e5ee234f4d1ce8a2a97e81d1c3e5e3e  linux-2.6.31.2.tar
f686666a2218afd13f2c6bc794919615  linux-2.6.31.3.tar
e2e84fc3cea9293517698f2af02e3698  linux-2.6.31.4.tar
a1518ae179af94eb840024655ed4471a  linux-2.6.31.5.tar
660348915031cc50ede9b6ae2028bf52  linux-2.6.31.6.tar
a0e27bc0c5a53a1a895c76d88a5acc1a  linux-2.6.32.tar
5be63bd57f8672db69198a8ec7a04637  linux-2.6.32.1.tar
32aa41fbc18fbe1cf1e8535e677c13a4  linux-2.6.32.10.tar
212f747ca5999b395bcc03799399b8ad  linux-2.6.32.11.tar
b73836b409909ba691e442a851221bab  linux-2.6.32.12.tar
1f72687582dd1bf5aa7d9a1b01ac11f5  linux-2.6.32.13.tar
8af1c02cefc69f902008b6d16e2a5f19  linux-2.6.32.14.tar
c86b467e8649d5b782e5c85d7bada2c3  linux-2.6.32.15.tar
34f9d86da519c3ac868bb6b9c0edf5fd  linux-2.6.32.16.tar
41fa851916eb3e208eb2d07d9a2edc20  linux-2.6.32.17.tar
e93ea8c463c761b6733ca9550de9d28d  linux-2.6.32.18.tar
baa03d63e6eb52c870ef5f4dee6bff81  linux-2.6.32.19.tar
cbd1bab8027a01ec42c28278879a7209  linux-2.6.32.2.tar
9b4b3ccbdb161284db7c50d8fa7a9cc4  linux-2.6.32.20.tar
4e2d3f2ca147c1d18a0c042bb39e8296  linux-2.6.32.21.tar
c1bbd1b7be8f5bc5b8ec845ba4cfa6d6  linux-2.6.32.22.tar
7706a8fa891540f5eaaf0b504505473d  linux-2.6.32.23.tar
e19d2bef8b40fe3870bb0b8e9bfa2f4b  linux-2.6.32.24.tar
1e8ea8d88db9ea220746c317c891c6d7  linux-2.6.32.25.tar
21db42cb4175753d6b702138b2d16035  linux-2.6.32.26.tar
f3b4b1aefc240a75b84ce8c83c1d8203  linux-2.6.32.27.tar
c63f9b5a3344f866620f6ae10be15881  linux-2.6.32.28.tar
a6546c1fad45fa336885860d31f89b9e  linux-2.6.32.29.tar
8dd90672223a82d8cbfa9bf0ecf6c70b  linux-2.6.32.3.tar
8b3e0d9612b61cdbf4a9a01566010fa4  linux-2.6.32.30.tar
5dcf526758804fa382f231073a442ebe  linux-2.6.32.31.tar
a3fd490344081ddc863c85e066c26de4  linux-2.6.32.32.tar
a22b0dd689764e1aa2abcbc4f3f38899  linux-2.6.32.33.tar
7c596527748f917b0df22321b83c9eb9  linux-2.6.32.34.tar
31b9c268a72f183b37a609ce1688ed33  linux-2.6.32.35.tar
21d809b12592e91d100f40ee9c415e94  linux-2.6.32.36.tar
88572d1d95f9417a93db60a954f3ce9c  linux-2.6.32.37.tar
75e4d93ea9c57c28acd169902c70ffe7  linux-2.6.32.38.tar
6d266224d3ff0d136b336228fe108f3a  linux-2.6.32.39.tar
2cf5b76b3aa71790215b45afcfa8906e  linux-2.6.32.4.tar
27cd2ab5f45c83effbca8f894b9bf9a4  linux-2.6.32.40.tar
3da56d911ae16e1d9d04d27e97140094  linux-2.6.32.41.tar
74189193fa0b44a74bfe31de2934396f  linux-2.6.32.42.tar
702e1151878c159021bfed717483d078  linux-2.6.32.43.tar
cc137ff7c3f9cd033bab9ddadfa09b9b  linux-2.6.32.5.tar
d1561434aa81622f6b17b72c8e00c226  linux-2.6.32.6.tar
c0fcd24b3b3783afefda8f77b0c95a03  linux-2.6.32.7.tar
2e09e2ecd521b5fb43cc577e88e98356  linux-2.6.32.8.tar
9e1ddce5bf49fbf740fe4967990b3f83  linux-2.6.32.9.tar
6fabba8f967b90f85e6ececa26531ddd  linux-2.6.33.tar
c604a96b1006c24da58237b9e55195a9  linux-2.6.33.1.tar
6453571f38b4dfaa602f7585a7616c48  linux-2.6.33.2.tar
a940c369b6d48fd3aea62d86d3a3b324  linux-2.6.33.3.tar

[-- Attachment #3: expected-hashes-022.md5 --]
[-- Type: text/plain, Size: 12564 bytes --]

f2f5e85a40255599e4efecae1aad3ac1  linux-2.6.11.tar
7d26979a123817f8386c12c5abb0e20d  linux-2.6.12.tar
8ae2c8d9d4f5cab99d4d21019dddf6a4  linux-2.6.13.tar
8ee2b4548d71cfa1079ecc2e30723434  linux-2.6.14.tar
2c970565ab3d24d56501091757359bb8  linux-2.6.15.tar
57e8bf34d91002fe115e1846cce95fdf  linux-2.6.16.tar
74c9b87042b6065a56682d67f17c451c  linux-2.6.17.tar
fa24e3245d8cb475ebffba763912063c  linux-2.6.18.tar
2630dcec21807a23b8f3c1d3463a9537  linux-2.6.19.tar
1c3a2b5f69f773e1ce3f02b0f3abddfa  linux-2.6.20.tar
c53647f3dbfd0ffd9654a0ce98b8d291  linux-2.6.20.1.tar
c1895c4103b5be384bee66b753d36ac9  linux-2.6.20.10.tar
f66b86d42fc446f2d411131689967c93  linux-2.6.20.11.tar
18e19f4cc550a39504e97193709153e5  linux-2.6.20.12.tar
171eb9fdd34f733e0922cd4b23071db5  linux-2.6.20.13.tar
482c40ff5cf7943f14592813c675d256  linux-2.6.20.14.tar
589d2a8a3c55e4ea72a62ad96aa1a414  linux-2.6.20.15.tar
8dcdeb70f40c510d722b860dafa09789  linux-2.6.20.16.tar
e6f79766425a02f118494c3eb6805bb0  linux-2.6.20.17.tar
6545281f0fb59df6570662d4161d3995  linux-2.6.20.18.tar
c08764a841602912d5515dabf35953b5  linux-2.6.20.19.tar
fe156af3eb690e4dad7481feb4a4f7d7  linux-2.6.20.2.tar
eb741f1bf898e4be5a8efde2a619cfaf  linux-2.6.20.20.tar
2152797bcda1ab3f7302a598bffb7c92  linux-2.6.20.21.tar
02e26f6b5c8cdb9bb6573612266d6a0c  linux-2.6.20.3.tar
1d399bf99ace7118fdb0b69088e391a7  linux-2.6.20.4.tar
54bc2907ecbbc6c73c086d14fec1c55a  linux-2.6.20.5.tar
4300abbeb91cc50b48c086c2c329eab8  linux-2.6.20.6.tar
806bf4868c54b8492cb093f0cd281a1c  linux-2.6.20.7.tar
f5d2ad11c38f09127140c3777fcfb824  linux-2.6.20.8.tar
6bb0a333bd1d94b3eabacdd03971f1b1  linux-2.6.20.9.tar
7965f0be6b6c1a4ff4e34336ba25d975  linux-2.6.21.tar
b87bffbddced0cbe25af2a3f72bab13c  linux-2.6.21.1.tar
623bacd2f2c231fc8edf2292a007be9b  linux-2.6.21.2.tar
e74b18f8e76943550f8534b2742f864e  linux-2.6.21.3.tar
28ad35c0a93b954ec3316547122a5bbf  linux-2.6.21.4.tar
3545e91362d563f6ff9924b695f533f5  linux-2.6.21.5.tar
d60d8d57f3d82c102324d8b729c596d0  linux-2.6.21.6.tar
021f3468f5e0bd7a5bee8469d13840f0  linux-2.6.21.7.tar
2edfd190ac09c0e5b998ab8514488cfa  linux-2.6.22.tar
b789c174edfd1c34a2c531b64e38ad64  linux-2.6.22.1.tar
3301c3caecf8f7f990d9accdab177ade  linux-2.6.22.10.tar
c6c542f71792080dbff1dcc583d4a518  linux-2.6.22.11.tar
aff348bca24814f561a8e5a5c908bcce  linux-2.6.22.12.tar
ab13c640b6420716feee1b520dd6b4b4  linux-2.6.22.13.tar
b82a63dcdae3ad14647cce9c43f51f3b  linux-2.6.22.14.tar
306cfe6a9d8cfaf195f3595ea269fb28  linux-2.6.22.15.tar
81cb91f23b2b21c94352eeb6ecb8082a  linux-2.6.22.16.tar
84e73c1861593689d20bc1d3c38d3e86  linux-2.6.22.17.tar
43e31521a204bc720c15d517aa034d8f  linux-2.6.22.18.tar
bc41726a2e88de45aea7ffc8e11fd5b7  linux-2.6.22.19.tar
46b9113ae5afb91c19a5fa63229982dc  linux-2.6.22.2.tar
633cde0652edd63a649058793943977f  linux-2.6.22.3.tar
805fd09a107609a9d5ea4f2a2631fe95  linux-2.6.22.4.tar
ad55bbb9edee79e6f1c3955d66cad35f  linux-2.6.22.5.tar
ec4ee470dfbe2f0d49b01cceb3a901eb  linux-2.6.22.6.tar
d1fd246bfef1afe7a971598832f75e7e  linux-2.6.22.7.tar
2b870ab6c247b7a16c3592bc2c90617c  linux-2.6.22.8.tar
d088d683b62911711ab05aa72bcccbcb  linux-2.6.22.9.tar
853c87de6fe51e57a0b10eb4dbb12113  linux-2.6.23.tar
19aee46bdd4577a4ba14ba51284cf791  linux-2.6.24.tar
2b8b848fcae4e1d4fb56c897e3a40c21  linux-2.6.25.tar
4f0443a7a1945c78ee7aefd65daab63b  linux-2.6.25.1.tar
3710353e8fb9ec0e5b7976946e8ad74a  linux-2.6.25.10.tar
46f205cf295de0722681c4a697913b17  linux-2.6.25.11.tar
0a9a7a979f1357430200ff19dd8ab9f9  linux-2.6.25.12.tar
0ce23a617201a6a77e00a05386a63b49  linux-2.6.25.13.tar
02aefcf5bf1f83bb8183d60f3554a876  linux-2.6.25.14.tar
edeb4d638af1061b1aa935d86d1eff21  linux-2.6.25.15.tar
21758a05e5ec21c4d26951de2fca5dc9  linux-2.6.25.16.tar
063547ad9ec9c7788c5e8fc85bf01dc4  linux-2.6.25.17.tar
9c862120cdcf5ab5dae6096dcc5e8e3e  linux-2.6.25.18.tar
272fcd11f8afb4e15ea2f9ed7701684c  linux-2.6.25.19.tar
0b21683d683c61caf7ed6a31148a730c  linux-2.6.25.2.tar
e34abaec1ead16ba8a37bc2d1af58235  linux-2.6.25.20.tar
8da85334dec70888ad7f5d9af383312c  linux-2.6.25.3.tar
4f93d14b812947bf5c3c714497abf981  linux-2.6.25.4.tar
f5589bf75e12ffa4a6d7c1409121fc25  linux-2.6.25.5.tar
7bc58e34dac2d19c87b0f6cf91701b8a  linux-2.6.25.6.tar
ae98119abe7c6d2ae3434e6128df2d0e  linux-2.6.25.7.tar
91c56c460e41c6cd3f51c207a21d8f3c  linux-2.6.25.8.tar
21d1a646fefc788ed6f350b6fa9bfee4  linux-2.6.25.9.tar
75aa7264f67777b0adf16bb38b2b90fa  linux-2.6.26.tar
f9fb49f756036a34d26eee85240ff8fb  linux-2.6.27.tar
8070c075076bfd9a127287b4971e805b  linux-2.6.27.1.tar
87974d79868688bfde542ae53a1b3125  linux-2.6.27.10.tar
2cbcf84c85d9c59e77fa914bd6bba761  linux-2.6.27.11.tar
b49d9e95fe93f446e01d4518b60bab69  linux-2.6.27.12.tar
570af87146476f11510326df0d8b3984  linux-2.6.27.13.tar
1f7905e190b577e05577ae69a87cfdd0  linux-2.6.27.14.tar
1f9774d0d3905f7c4c26eccfcbd39a32  linux-2.6.27.15.tar
a25b9ff42e4118dadbf91dab177cf729  linux-2.6.27.16.tar
11dda14a935da891297aad6ac63963b9  linux-2.6.27.17.tar
6c52ca1c6d7873c7b1c7137604fae0fb  linux-2.6.27.18.tar
5364290f657196744241a03083035701  linux-2.6.27.19.tar
3b4cbe544080882fecb9253ab4b86302  linux-2.6.27.2.tar
7ca7c36744e934af1727edb8da469c06  linux-2.6.27.20.tar
615bfa2d1d5efd8979afb44b564e7ef6  linux-2.6.27.21.tar
4ff50b881758279609c46bd9d1836559  linux-2.6.27.22.tar
74563dfe5e3d75ac620cd7b3e932078e  linux-2.6.27.23.tar
9c9ec6ac35b0526c26ec0b1ac78602d2  linux-2.6.27.24.tar
964946e63215d1ba1e54443e04c152dd  linux-2.6.27.25.tar
0e5bcbc4dc72f824a167b6a6ccaf9827  linux-2.6.27.26.tar
76f8c62fd84fe5bd1cbc127e480ac874  linux-2.6.27.27.tar
0a71df8639d914466dd6aaa3eb41aae9  linux-2.6.27.28.tar
522242271924801f5733d58a78191317  linux-2.6.27.29.tar
ea861bd74b8557efe9eff8fbecdece93  linux-2.6.27.3.tar
469eed11a3d554d505a9c45320850e63  linux-2.6.27.30.tar
b2c2b26d24a1adc627964ae38ece6d8a  linux-2.6.27.31.tar
89e8b659a186973968e38ae954a4eb94  linux-2.6.27.32.tar
ac62902bae7986900cb1fc6d6a515069  linux-2.6.27.33.tar
f7f09bed6ba9b43b4869acccce651799  linux-2.6.27.34.tar
04f97cb04659e5766c3d6d98a4a61b49  linux-2.6.27.35.tar
13e359ac044ab939a1099527d9273c0e  linux-2.6.27.36.tar
42840afc0212c344d7da63e324578194  linux-2.6.27.37.tar
1c362fc95fce9d75ad1cb5d2008bd0e5  linux-2.6.27.38.tar
35270ba7035121ba412a1b0c9ad858c6  linux-2.6.27.39.tar
fa68f25239bd1749e4964a1fbab799de  linux-2.6.27.4.tar
b46cd8e6cbedac278897e162b6d0ec9a  linux-2.6.27.40.tar
e2b58b73ceba4c87c67d016721d9a114  linux-2.6.27.41.tar
758ad666cfb701bafe6fc629a32198df  linux-2.6.27.42.tar
40b4bf9a28021d66d78a08679b8b83ca  linux-2.6.27.43.tar
02838773b9b90590e13b0d1a06a4ac9f  linux-2.6.27.44.tar
1387eee67e915ebb560db850dc3bbbd3  linux-2.6.27.45.tar
49f442f32325dde72aa36106308e6b79  linux-2.6.27.46.tar
6029c88ed971e0b0027da5dcc2c6279a  linux-2.6.27.47.tar
336ff978d5ae1b5423e7d9a32bbf8ddb  linux-2.6.27.48.tar
dc3733da9c995546ade6cb9bbee04ff4  linux-2.6.27.49.tar
f4905352c9554e66ca96ec204f0f9eaf  linux-2.6.27.5.tar
5ef7354428412a4ea1f75092e222d321  linux-2.6.27.50.tar
7030272c8c35ef0635fd0ec626bbf85b  linux-2.6.27.51.tar
b01521d39e2b1f9aabc5330553c0430f  linux-2.6.27.52.tar
d471e1ded08f9b2412c52e72cc84b8b3  linux-2.6.27.53.tar
f5af02a82c0b499ef96a42d77d60bfd5  linux-2.6.27.54.tar
82143acbd35fc038803c7b7b8e613dc4  linux-2.6.27.55.tar
a83cdc2128fc495cec962e7999b273aa  linux-2.6.27.56.tar
8e42fc7abc073732992d94de5fed687d  linux-2.6.27.57.tar
3e169f917524e59cb796b4c8b2798a18  linux-2.6.27.58.tar
1b8085b5a66ccbd0801ed8370ba090e6  linux-2.6.27.59.tar
35332c4ad162bd77f82df4c2d8c00338  linux-2.6.27.6.tar
1a0d2054b80f5816003c52d9bf0723b1  linux-2.6.27.7.tar
3c3febbd1db7a7b8ddfc6beb14255f3f  linux-2.6.27.8.tar
f775d1b1f8f6afac87f3c52af73b1b26  linux-2.6.27.9.tar
afb7b848123b8f2df42cf42f0845860f  linux-2.6.28.tar
f614a023dd7a9b38303a35aebedb3a4d  linux-2.6.29.tar
eb49381facbe064063ea3e57cfb4a906  linux-2.6.29.1.tar
d741e8ee0907382bbde85a38ae339306  linux-2.6.29.2.tar
d958cca6c8fdce6dc11fc41e70d5778f  linux-2.6.29.3.tar
d2a53cd35c4a0527932c7c558aa5fe40  linux-2.6.29.4.tar
62375464059dfd8f98345e560546de27  linux-2.6.29.5.tar
88820d065779ce517d03e6c19c9d3198  linux-2.6.29.6.tar
2bca7fef9e6aeaafcf4d34740c2a511e  linux-2.6.30.tar
48dd001c8abb29f6caa686ac5c1dbd58  linux-2.6.30.1.tar
41e301a9a711c98fadfdaace0780a31e  linux-2.6.30.2.tar
59cf51a5461eb418b7d6cc70eadea0d3  linux-2.6.30.3.tar
9b5bfc1bc2cf09efe9259f9257248828  linux-2.6.30.4.tar
0c31aa5f6d63d839672d905c659f87f6  linux-2.6.30.5.tar
3da8c653652dd312b5054eef32fdb9c3  linux-2.6.30.6.tar
9f7800ac2ccf8b6ed4dd588301483e01  linux-2.6.30.7.tar
10f187cd3037ef63b870471809bf7123  linux-2.6.30.8.tar
79668ae100b542b0484424c8ff84cd5e  linux-2.6.30.9.tar
153f6267e44f5d32a364aa61e2b8c537  linux-2.6.31.tar
dbc4419d2ea5063da881a55ec9a0cd12  linux-2.6.31.1.tar
bd0c7eb6ca9349f5ce36bc918e9f342d  linux-2.6.31.2.tar
d0034f4a1b64e3ec8e39c6282ecbbe4c  linux-2.6.31.3.tar
5c61245d5206c8264172f7b529da3ab7  linux-2.6.31.4.tar
42a2f9fdbc51153d4ebf12248b388f17  linux-2.6.31.5.tar
87d1bbe2e52c7926aab04216ebf06aff  linux-2.6.31.6.tar
d1fef908e3b72c37b925e1a399d1a035  linux-2.6.32.tar
fbb0b53fd5f988a5045eb9ff0cf00c70  linux-2.6.32.1.tar
797b6fc1597310f439e206db4bb27a95  linux-2.6.32.10.tar
4c1d7f4e153aebcd9d11963f8622dbb6  linux-2.6.32.11.tar
f10c5ee16cd40b43dba061dfbaba986d  linux-2.6.32.12.tar
2245a91ee485ab622a0143bc4d356f84  linux-2.6.32.13.tar
e3dc9f94dc0b0758332e9d271509cb33  linux-2.6.32.14.tar
3939d945e2ca1f9a37d46c32c272a872  linux-2.6.32.15.tar
dfa36a1c0d21b94ba55510529244825a  linux-2.6.32.16.tar
54a703b26431ed63abeca026df0a289a  linux-2.6.32.17.tar
eb555d35de13dca895e764deb52da0f7  linux-2.6.32.18.tar
7f89366a08f21d0d22dd407153fcc3b9  linux-2.6.32.19.tar
715105f99c1c441251bad5f00e7f839d  linux-2.6.32.2.tar
6ce7e916ac84d00cef09bcbbb6ef7f16  linux-2.6.32.20.tar
609a992d3bbc0fd7ef96602053ac0634  linux-2.6.32.21.tar
f05a06b85c7859be85547ad2d1e1abe7  linux-2.6.32.22.tar
87f10b9d179aebdf57f7e852336492f2  linux-2.6.32.23.tar
581079e6aa1207aafe62aa2037bb5b50  linux-2.6.32.24.tar
6b6b653f08b9a2cee09b2efbd935edd5  linux-2.6.32.25.tar
eb0d49fb9de6720050db1f7da860d285  linux-2.6.32.26.tar
ef045b2aafa4baa7b146341016477bac  linux-2.6.32.27.tar
07052ac799fdc6edc591637c482f42e9  linux-2.6.32.28.tar
fe8f32125281589fd8f3dab91e7fafe1  linux-2.6.32.29.tar
da4b91ef37cb14c04f9ee3dcdf0a4cf2  linux-2.6.32.3.tar
fda8f11240d61fd8f669894b140e5b6d  linux-2.6.32.30.tar
e89884177b8e156cf6b8f0f8e2aac303  linux-2.6.32.31.tar
37e8c1c80bd65d5cc4a991f45dd0067b  linux-2.6.32.32.tar
0f2e9723c2821cb435041dd7944565fc  linux-2.6.32.33.tar
97aaabc9df34d09e569eacbfe4e43377  linux-2.6.32.34.tar
a133670d718d19944b5b33814b9b92a3  linux-2.6.32.35.tar
d3519959ea3d63f0176c001625661f6e  linux-2.6.32.36.tar
561265c5b5393f15302f46c20259cbaf  linux-2.6.32.37.tar
8317b49e04e0c85ad63b68df6b79b326  linux-2.6.32.38.tar
482cd728efd74c4337144276dd3807ad  linux-2.6.32.39.tar
3d711da17861729c3dcaa5f33c3d0ad2  linux-2.6.32.4.tar
2ac2a01c5b81f8226ca6f7bf5c316c86  linux-2.6.32.40.tar
cd72c28909bdf666d22a35a97b583a5e  linux-2.6.32.41.tar
1f1b463e59c4354ce58510b3f975d2c7  linux-2.6.32.42.tar
db32d5d6478de235462d0952ae183bc8  linux-2.6.32.43.tar
7855f7a563a78be687ef15742fe02cb0  linux-2.6.32.5.tar
9330517770a6fbac7e83a009c80e2764  linux-2.6.32.6.tar
05272bb905652db15bfa5c9b1d09d706  linux-2.6.32.7.tar
f073b45bdf76126b9687f7a929131a52  linux-2.6.32.8.tar
29f6f3d95c7922871ba2b1b3d7370a11  linux-2.6.32.9.tar
7fb6c834df94d78ad1dc118ba98bab21  linux-2.6.33.tar
b2e6e14d8d7649d646662484fc649c64  linux-2.6.33.1.tar
ba7df33c0624858c017ce9d483026a1c  linux-2.6.33.2.tar
5db2fe84a481b82b18138d89b90d9533  linux-2.6.33.3.tar
daeb9d57e70ec0b04ac9d5fa13f3fd47  linux-2.6.33.4.tar
ef8a509eec6cb18e729ce79c824eb184  linux-2.6.33.5.tar
b36063fb6a50e736dc65f1798b4ec12f  linux-2.6.34.tar
76e96f2df4eeea351787c65b3b264986  linux-2.6.35.tar
b08724cbafa37379d7a4bca54637e203  linux-2.6.35.1.tar
b8bdcb17f235805dd3c5bdb6e51e672a  linux-2.6.35.10.tar
4facab5d0b2099b3d49142d862c1bedf  linux-2.6.35.11.tar
e07069bc483e1f222ed676689191f0e4  linux-2.6.35.2.tar
9092ada8d2f742022689c8ef556df867  linux-2.6.35.3.tar
926e86cdbc597a6d002de9084882dde9  linux-2.6.35.4.tar
3617b069536ebe589590577875479f9d  linux-2.6.35.5.tar
33d48a4a4f857e702b6e88a11041135e  linux-2.6.35.6.tar
2ab3b2bf1fd6943c4e502b790318cefb  linux-2.6.35.7.tar
32fc3af98d7f190b16005ad3bfc5113f  linux-2.6.35.8.tar
6f8e194a28b3bb1829a1fc6f022f4221  linux-2.6.35.9.tar
2f4d3b5d66aa1c1465e0c05e3c5f36ac  linux-2.6.36.tar
943a4f25288d86b1dbf7808eb539bd42  linux-2.6.37.tar
0e705fd53756f7bddcf6e4bb3f18458b  linux-2.6.38.tar
833d224ee42ddc1e7c2d256368b5d7b3  linux-2.6.39.tar
4de04c36ae76c37269f156c13e75aa73  linux-3.0.tar

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Sat, Oct 01, 2011 at 09:06:12PM +0200, Willy Tarreau wrote:
> On Sat, Oct 01, 2011 at 01:40:44PM -0500, Andy wrote:
> > On Sat, Oct 01, 2011 at 07:54:56PM +0200, Willy Tarreau wrote:
> > >   $ git config tar.umask 022
> > 
> > Andreas/Willy:
> > 
> > It was indeed umask which was skewing the results. Thanks.
> > 
> > Now, I'll wait for Willy's hashes since I can't drill down on
> > Linus' 2.6 tree beyond 2.6.x.
> 
> OK I'm attaching two files, one computed with the initial 002 perms and
> a second one with the new 022 perms. I don't precisely know when the perms
> changed, hence the two files. I noticed that 2.6.25 was still 002, and that
> 2.6.32 was 022. In between I don't know. Note that I'm missing some tags
> (at least 2.6.35.12 and a few 2.6.33.x and 2.6.34.x).
> 
> The file is formated to be easily used with "md5sum -c" that dirty way
> (once hashes are split/joined at the location where the umask changed) :
> 
>   cd /path/to/mirror/2.6
>   cp linux-*.tar.gz /tmp
>   cd /tmp
>   gunzip linux-*.tar.gz
>   md5sum -c expected-hashes.md5
> 
> It would be nice if someone with an access to a mirror could check the
> perms of *every* tarball so that we can establish the definitive list
> of signatures. I'm pretty sure the umask history is not linear. For
> instance, I'm pretty sure I did not change the umask in my config when
> releasing 2.6.27.x kernels and it seems like Greg did not do this either
> so we have 2.6.27 022 and 2.6.27.x 002. Something like this might do it
> (untested) :
> 
>   for i in linux-*.tar.gz; do
>     set -- $(tar tvf $i|head -1)
>     [ "$1" == "drwxrwxr-x" ] && echo "$i 002" || echo "$i 022"
>   done
> 
> Hoping this helps a bit.

Very nice, thanks so much for providing an independant verification of
the tarballs, it is much appreciated.

And yes, the umask problem did trip us up when we did the initial
verification as well, fun to see that you all figured out and solved the
problem faster than I did :)

thanks again,

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

On Sat, Oct 01, 2011 at 12:24:38PM -0700, Greg KH wrote:
> Very nice, thanks so much for providing an independant verification of
> the tarballs, it is much appreciated.
> 
> And yes, the umask problem did trip us up when we did the initial
> verification as well, fun to see that you all figured out and solved the
> problem faster than I did :)

I found that one of the remote machines I have access to has a fast
access to a mirror. So I'm currently collecting tar.gz sigs and tar
sigs. I stopped checking bz2 because that small machine takes 20s to
bzcat one file (for <1s file transfer)!

I discovered that 002/022 are not the only differences. Adrian used
to set 2.6.16.x at umask 000, and Linus changed the user in the
tarballs several times (torvalds, then git, then root). I'm also
seeing a certain greg/users for 2.6.11.x :-)

I think it will be easier to reproduce the sigs from the tags once
we have all the elements to know how the tar files were produced.

I'll post the tarball sigs here once I get them all. That way it
will already be possible to check if different ones are found on
some mirrors.

Willy

Re: kernel.org status: hints on how to check your machine for intrusion

[Andy]

On Sat, Oct 01, 2011 at 09:06:12PM +0200, Willy Tarreau wrote:
> OK I'm attaching two files, one computed with the initial 002 perms and
> a second one with the new 022 perms. I don't precisely know when the perms
> changed, hence the two files. I noticed that 2.6.25 was still 002, and that
> 2.6.32 was 022. In between I don't know. Note that I'm missing some tags
> (at least 2.6.35.12 and a few 2.6.33.x and 2.6.34.x).

Very helpful Willy, many thanks for doing this.

> It would be nice if someone with an access to a mirror could check the
> perms of *every* tarball so that we can establish the definitive list
> of signatures.

I agree, would be nice to fill in the few gaps.

~ Andy

Re: kernel.org status: hints on how to check your machine for intrusion

[Andreas Schwab]

Willy Tarreau <w@1wt.eu> writes:

> I discovered that 002/022 are not the only differences. Adrian used
> to set 2.6.16.x at umask 000, and Linus changed the user in the
> tarballs several times (torvalds, then git, then root). I'm also
> seeing a certain greg/users for 2.6.11.x :-)

Obviously tarballs before 2.6.12 weren't created with git-archive and
will contain unpredictable timestamps.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

On Sat, Oct 01, 2011 at 10:29:54PM +0200, Andreas Schwab wrote:
> Willy Tarreau <w@1wt.eu> writes:
> 
> > I discovered that 002/022 are not the only differences. Adrian used
> > to set 2.6.16.x at umask 000, and Linus changed the user in the
> > tarballs several times (torvalds, then git, then root). I'm also
> > seeing a certain greg/users for 2.6.11.x :-)
> 
> Obviously tarballs before 2.6.12 weren't created with git-archive and
> will contain unpredictable timestamps.

I did not remember when the git-tar command was introduced, but your
comment makes a lot of sense ! We're not much interested in 2.6.11
anyway I think.

Regards,
Willy

Re: kernel.org status: hints on how to check your machine for intrusion

[Henrique de Moraes Holschuh]

On Sat, 01 Oct 2011, Willy Tarreau wrote:
> > > I haven't allowed sshd to run on port 22 in more than 10 years.
> > 
> > I use to do that a long time ago, but I ran into issues because of it.

...

> 443 is pretty nice for connecting from unexpected places ;-)

The better IPS/IDS-protected corporate networks are likely to get annoyed by
SSH signatures showing up on unexpected flows.  Such networks typically will
also object to non-SSL flows of any sort over port 443.

YMMV.

> > I probably can go back to a non 22 port without much issue. I have added
> > a bunch of personal checks to this box that gives a report every day. I
> > may add more (from what was posted in this thread already). I also have
> > logwatch and rkhunter running, and just added chkrootkit now.
> > 
> > But moving the ssh port again may be a good idea. But I like stressing
> > your net filtering code ;)
> 
> BTW ipset is particularly suited for this.

And fail2ban is a ready-made solution to firewall anything that is loitering
around.  It is quite popular, so it is likely already packaged by the
distro.

There is no reason to move SSH from port 22, it is just plain safer to use
port-knocking if you want it unreachable most of the time.  You should also
avoid password-guessing attacks entirely (some botnets can do distributed
low-speed password guessing attacks, I've seen it happen at work) by always
requiring pubkey auth as one of the credentials.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: kernel.org status: hints on how to check your machine for intrusion

[Henrique de Moraes Holschuh]

Hmm, and a last tip:

Always use the "AllowUsers" or "AllowGroups" directive in sshd_config to
only allow access to whitelisted users/groups and deny to every other user
(including system ones).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

Hi,

On Saturday, October 01, 2011, H. Peter Anvin wrote:
> Hi all,
> 
> Since the kernel.org status announcement last week a number of you
> have contacted me about re-establishing credentials.  In order to
> establish a proper PGP web of trust we need keys that are cross-signed
> by other developers.  As such, we ask that you follow the following
> steps:
> 
> 1. Make sure your systems are uncompromised.  We will address specific
>    recommended steps for that in a separate email.
> 
> 2. Create a new PGP/GPG key, and also generate a key revocation
>    certificate (but don't import it anywhere -- save it for the
>    future) for your new key.  In the near future we are considering
>    setting up an escrow service for key revocation certificates.
> 
>    I recommend using a 4096-bit RSA key.  Given how fast computers are
>    these days, there is no reason to use a shorter key.  DSA keys
>    should be considered obsolete; substantial weaknesses have been
>    found in DSA.
> 
>    $ gpg --gen-key
>    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke

OK, how long should the new key be valid?

Rafael

Re: kernel.org status: hints on how to check your machine for intrusion

[Frank A. Kingswood]

On 01/10/11 19:06, Steven Rostedt wrote:
> On Sat, Oct 01, 2011 at 09:35:33AM +0200, Willy Tarreau wrote:
>>
> For my machine that is connected to the outside world, I have a script
> that runs every night that checks for attacks. As bots constantly look
> for port 22 and 80, they find my machine without issue. When my script
> detects a bunch of ssh login attempts that fail, it will add that ip
> address to the iptables DROP chain:
>
> # iptables -L -n | grep DROP | wc -l
> 2656
>
> I've picked up quite a few ;)
>
> This script only runs and scans once at night. Probably better to have
> it run more often.

Limiting SSH accesses to a few a minute (failed or not) is useful to 
block many password guess attacks. I set up mine a long time ago 
following this article using "recent" matches in iptables:

http://www.debian-administration.org/articles/187

You'll want to set the same rules for ipv6.

This won't stop low frequency and distributed attacks, and sometimes but 
extremely rarely I find myself connecting more quickly than the rate limit.

Setting "PasswordAuthentication no" in your sshd_config is good too.

Regards,

Frank

-- 
------------------------------------------------------------------------
Frank A. Kingswood                      frank@kingswood-consulting.co.uk
Cambridge, United Kingdom                               +44-870-095 0000

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Saturday, October 01, 2011, Greg KH wrote:
> On Fri, Sep 30, 2011 at 04:50:37PM -0700, H. Peter Anvin wrote:
> > 2. Create a new PGP/GPG key, and also generate a key revocation
> >    certificate (but don't import it anywhere -- save it for the
> >    future) for your new key.  In the near future we are considering
> >    setting up an escrow service for key revocation certificates.
> > 
> >    I recommend using a 4096-bit RSA key.  Given how fast computers are
> >    these days, there is no reason to use a shorter key.  DSA keys
> >    should be considered obsolete; substantial weaknesses have been
> >    found in DSA.
> > 
> >    $ gpg --gen-key
> >    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
> 
> I would recommend a physical access device for your new gpg key that you
> create.  I've heard good things about this USB device:
> 	http://www.crypto-stick.org/
> and am trying to have a bunch of them at the Kernel Summit this year to
> hand out to people if they want one.

This thingie is only capable of operating keys up to 3072-bits it seems.

Thanks,
Rafael

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Sun, Oct 02, 2011 at 12:07:45AM +0200, Rafael J. Wysocki wrote:
> On Saturday, October 01, 2011, Greg KH wrote:
> > On Fri, Sep 30, 2011 at 04:50:37PM -0700, H. Peter Anvin wrote:
> > > 2. Create a new PGP/GPG key, and also generate a key revocation
> > >    certificate (but don't import it anywhere -- save it for the
> > >    future) for your new key.  In the near future we are considering
> > >    setting up an escrow service for key revocation certificates.
> > > 
> > >    I recommend using a 4096-bit RSA key.  Given how fast computers are
> > >    these days, there is no reason to use a shorter key.  DSA keys
> > >    should be considered obsolete; substantial weaknesses have been
> > >    found in DSA.
> > > 
> > >    $ gpg --gen-key
> > >    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
> > 
> > I would recommend a physical access device for your new gpg key that you
> > create.  I've heard good things about this USB device:
> > 	http://www.crypto-stick.org/
> > and am trying to have a bunch of them at the Kernel Summit this year to
> > hand out to people if they want one.
> 
> This thingie is only capable of operating keys up to 3072-bits it seems.

For older versions of gpg, yes, as of gpg version 2.0.18 it can handle
4k bit keys, so all should be fine.  Read deeper on the site, it says
this somewhere there.

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/01/2011 02:33 PM, Rafael J. Wysocki wrote:
> 
> OK, how long should the new key be valid?
> 

That is a good question.  At the very least you want it to be valid for
long enough that you will be able to get enough signatures on a new key
*before* your old key expires.  As such I would recommend 3-5 years
depending on how much you trust yourself to keep the key secure.

Some people have decided to opt for an unlimited key, but that
*requires* that you have a way to revoke the old key, which is why we
are considering a key revocation escrow service.

	-hpa

Re: kernel.org status: hints on how to check your machine for intrusion

[H. Peter Anvin]

On 10/01/2011 10:54 AM, Andreas Schwab wrote:
> Andy <akwatts@ymail.com> writes:
> 
>> I must be doing something wrong. I only have the 2.6 git repo (so my tags
>> don't drill down to 2.6.x.y just 2.6.x) but my experiement isn't giving
>> the results I expected.
>>
>> [Cloned repo]
>> $ git archive --format=tar --prefix linux-2.6.39/ v2.6.39 | md5sum
>> 482f8bd941def0548a95f34e2d290dfd  -
> 
> Try setting tar.umask to 022 (default is 002).
> 

One thing to be aware of is that tarballs produced with git before
version 1.5.0-rc1 (mid-January 2007) have owner/umask git/git 000 as
opposed to root/root 002 or 022.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Randy Dunlap]

On 10/01/11 15:27, H. Peter Anvin wrote:
> On 10/01/2011 02:33 PM, Rafael J. Wysocki wrote:
>>
>> OK, how long should the new key be valid?
>>
> 
> That is a good question.  At the very least you want it to be valid for
> long enough that you will be able to get enough signatures on a new key
> *before* your old key expires.  As such I would recommend 3-5 years
> depending on how much you trust yourself to keep the key secure.
> 
> Some people have decided to opt for an unlimited key, but that
> *requires* that you have a way to revoke the old key, which is why we
> are considering a key revocation escrow service.

Who needs these privacy keys?  Is it just (git) users of kernel.org?

so people who send patches via email do not need to do this process?
or are we headed into sign-all-patches territory soonish?

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

[-- Attachment #1: Type: text/plain, Size: 3449 bytes --]

On Sat, Oct 01, 2011 at 01:40:44PM -0500, Andy wrote:
> On Sat, Oct 01, 2011 at 07:54:56PM +0200, Willy Tarreau wrote:
> >   $ git config tar.umask 022
> 
> Andreas/Willy:
> 
> It was indeed umask which was skewing the results. Thanks.
> 
> Now, I'll wait for Willy's hashes since I can't drill down on
> Linus' 2.6 tree beyond 2.6.x.

OK, I already have something. For now I have all the tar.gz and the
extracted tar hashes, and a number of the git hashes. I'm appending
the file, it's incomplete, as I'm missing some git tags (hashes are
then marked "xxxxx...xxxx".

The file is formated like this :

  <version> <umask> <user> <group> <tag md5> <tar md5> <tar.gz md5> <status>

Since I can attest that I exclusively extracted the tarballs from the
tar.gz and dumped their md5 at the same time, I'm pretty sure that the
tar.gz's md5 is OK if the tar's md5 is OK. This will help speed up sig
checks on mirrors.

All the times I got a different MD5 between the tarball and the git
tag was because of a different user name in the tarball. It seems
that old git versions used to use "git/git" instead of "root/root"
now. This is hardcoded so it's not easy to change it, and I suspect
that the tar format might have changed a bit, so if we want to check
those MD5s, either we check on old mirrors that are 100% safe, or we
have to reinstall an old version of git. The differences are for the
following kernels only :

2.6.11 002 torvalds torvalds b390eb0350b4f953a53c16dd5c28810e 6aa8e0b14cdab0757b9474e1a7fb3124 41bb11f9ec307706683c5661f140123e
2.6.12 022 git git 7d26979a123817f8386c12c5abb0e20d 2fbb5cbd5fe9b57861c6e4167a292613 6050857c0808975dc0ee58bc9804ee20
2.6.13 022 git git 8ae2c8d9d4f5cab99d4d21019dddf6a4 e0f2e6fe9c81a01b3d69ff4454e0c415 8978c9b3976fae17923ef3e511b54a26
2.6.14 022 git git 8ee2b4548d71cfa1079ecc2e30723434 9214cedf82c7c5f5639fe40e7c77139a 396029ab7d62bce01122ac50c004a43f
2.6.15 022 git git 2c970565ab3d24d56501091757359bb8 6adddd15e10f2ff228c70733e2e762b3 873a00a1a20d7ccaad2eedc98109d6e1
2.6.18 022 git git fa24e3245d8cb475ebffba763912063c ad43dd75219d9e6a8a9460bbf5f65b3e bc483723670bda09198d72293e712d42
2.6.19 022 git git 2630dcec21807a23b8f3c1d3463a9537 be8a46187734cdb911bb4aa37f864f5a 267a9479c6c6a79a0b2f511ddcc17147
2.6.20.6 022 git git 4300abbeb91cc50b48c086c2c329eab8 a4acbfe6fc54823d96dc257a2595257f fdd2e0336ec063cb8f6a4f36b0a3d257

So far, according to the attached list, 225 out of 478 checked kernel
versions are valid, and I have not found a kernel with an unexpected
mismatch. I have appended a "GOOD" flag on their line. The equivalent
md5sum file can be built this way :

   awk '/GOOD/{print $7"  linux-"$1".tar.gz"}' 26-report4.txt > 26-good.md5

... or it may be fed to md5sum directly :

   awk '/GOOD/{print $7"  linux-"$1".tar.gz"}' 26-report4.txt | md5sum -c

Please note that longterm kernels were moved to specific directories,
which made it a bit cumbersome to retrieve the kernels. There is no
reason it will be easier for you to check your files ;-)

I'm still downloading and extracting all tar.bz2 files to compare their
sigs with the ones in the current file. That way we'll have the whole
list with all reference MD5 sigs available.

I would really appreciate it if someone who has all the missing tags
would fill the entries which currently are marked "xxxxxxxx".

For now I did not consider 3.x since it's in a different download
directory. We might check that later.

Regards,
Willy


[-- Attachment #2: 26-report4.txt --]
[-- Type: text/plain, Size: 59474 bytes --]

2.6.0 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1070dd17ae93b86776c166efc73eb18b 97067974e4a490aa533fae78ff7a424c
2.6.1 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f10b247510edd03159634d9309398e1d 6cc71be409c58ea44f5aec5d52f4de30
2.6.2 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5b23fc3f726335ae8c1946bd2c625a41 f975be5855f0d9aa7dd169ad7febebd2
2.6.3 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5b1837a52ceb92d71583c387d4fabc8f eecc98f673e135f3a7c0f58443f4ce07
2.6.4 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1aa9881e84c4c4f9e0a17c7914ce3605 43638c35be21f58102fb27ae81b439c0
2.6.5 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5db67c27afb2cfd5d4c52ae1e20f38f4 8eb83dc7ac8608d50086123495af8720
2.6.6 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eaf803a496e7b8458ba332b04b89c0c0 f4f8f0f5e67205c366a785b1535bce7f
2.6.7 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 104de8f7f6dbf6b84a8089ead4242565 5a1f770ee96b0944added4f7326afc24
2.6.8 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d14c5dda32e59dad1ace7ebc537cc493 c91448746afc266197fd0da9b3638311
2.6.8.1 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx deda8b8cf299a39418743e14e58ab8f0 98f93075c7c24e681eaf7e70783af5e4
2.6.9 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5c715f55156f8979379c8a749c0bfaed 659eaab11678d84c33c6816bd4c6e6ba
2.6.10 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 720f5102649c0cfc2c078945fc640feb ec711367f805ffff0e6ee82bc736582e
2.6.11 002 torvalds torvalds b390eb0350b4f953a53c16dd5c28810e 6aa8e0b14cdab0757b9474e1a7fb3124 41bb11f9ec307706683c5661f140123e
2.6.11.1 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3cf9eae4f95646ae0ffc2d0b83d8868f 6bc1253824cbe6ddc4d39f501b8f8882
2.6.11.2 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f13a1007df661c8e1e37523ab5da1673 147fc341abb88cf1127d98929d4bcfc5
2.6.11.3 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 12212767ac29e6eea5fd3e839569723d acb17b2519957273da523047e512d15e
2.6.11.4 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7259709a5cb8a0b5a48976a320527d48 a9f0512169b0f9158c65632d4cfd1318
2.6.11.5 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 69b34aa9bd308ae09938c7a79f36e939 45e89928a4630c203cdf308382aba56f
2.6.11.6 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 068edd6dfc720d7f25511a275afad102 90a33341f6d4d8067de9c33cb8d05c1f
2.6.11.7 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7912910e72409daab452a0833db1a848 0fdda93c77077070d81e6880b1cf0933
2.6.11.8 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7e8b246a232e811c754dadc3ccdb8aa2 042bbb773d055189a3b1bad75a064663
2.6.11.9 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6f4f40d71259fdde0e4b00671768219f 191f324879bc7a9d4ccf866f6ac3c596
2.6.11.10 022 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3e66cec82b7246be2b3f49e0faae9e9a 38b1c4956c621d8dbe3d717d0e6ced37
2.6.11.11 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0e159ca8748e2862c9c069e3e9294cac 21af9bfdf3e49d1b1e208634104dc5d0
2.6.11.12 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a655292e4c558d05ebf9cb77d4bfe1da 1fa49d3534cc9b3a3fc97c17b7e8207e
2.6.12 022 git git 7d26979a123817f8386c12c5abb0e20d 2fbb5cbd5fe9b57861c6e4167a292613 6050857c0808975dc0ee58bc9804ee20
2.6.12.1 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b94eb2e6c5039d24a453a95f2e0bd777 343d169f40ffc15a9116aa6cd82e9ea5
2.6.12.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cbec68c32311ea3145017f8f8669d523 ef8385b5a34be8c44d111e9fb3b85fa8
2.6.12.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0f4614744cc9e737c41ad6ddbc863627 ab42137978ea1749c485b894ebd48031
2.6.12.4 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a50aec151cb375c6bb446fe2d69fc807 752efdbd3cba5c96109c536d31a6a6cd
2.6.12.5 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6901d7d629030e24f56a13a7e321446e edcdfd602718ad7282a248cfe60848d3
2.6.12.6 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 128bc1c572f16cc23e9bda381d507dd4 dc2b54aff74653aa2175d2bfad9fb934
2.6.13 022 git git 8ae2c8d9d4f5cab99d4d21019dddf6a4 e0f2e6fe9c81a01b3d69ff4454e0c415 8978c9b3976fae17923ef3e511b54a26
2.6.13.1 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d30e76b0286f79355041e1fead721a87 88ce10010ed54973122e07e0c8495117
2.6.13.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8a62c4b78f7b385d5d5fe0fb402bef39 6b2e04f2ba74552554b606a335d41fd2
2.6.13.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 39f7bb153b6718214b0a0b8eb47db48c fe9d89025a343196410d812ab1c8013b
2.6.13.4 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 015640711c8c108732fb4fd0cf693ef0 9f4aab3cddacae3bcc7887a1c90412c9
2.6.13.5 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 72a599f2c649c9d6cdda1e61bfd2f06a b0a5e640e8d9c61d311365f5b4e82035
2.6.14 022 git git 8ee2b4548d71cfa1079ecc2e30723434 9214cedf82c7c5f5639fe40e7c77139a 396029ab7d62bce01122ac50c004a43f
2.6.14.1 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ef4ba1942a38cdf2625bf9d4e98a22d9 93206b5d82bea0aa5a72cda37fc374a2
2.6.14.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 202e8e48a2a89e223fef1a5fa2c29ba0 aeab2d967a6710339c96a2a16ca9c361
2.6.14.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 57fcc3a29faf0e15b3bf85eb68cf783a fc784ab07783c6caa75cab76879bcb0d
2.6.14.4 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx df85eb0756950e685834b69d2584f7d5 dc84028e3f485563213d88c576613ee7
2.6.14.5 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4d7e78745ba357e2c5bf131353ca5734 3aaf9adaff17d4e1cd66b067059977ab
2.6.14.6 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 383c9ca1ef8a08d3fb5b942b15728dfd cc4a7f327c69101550a5c09b56716f08
2.6.14.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 64979b947b941845d3d53fa25dba75d6 762edf1bcf5ecfbc224dae4ea4eb0c40
2.6.15 022 git git 2c970565ab3d24d56501091757359bb8 6adddd15e10f2ff228c70733e2e762b3 873a00a1a20d7ccaad2eedc98109d6e1
2.6.15.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3621e51fac1197238b31bf832f9a9231 9a967e67e202ba898cec83a88996e63f
2.6.15.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2b3983c48ca97fb8d0c7a9a8243b9f65 b1296fadb23dcc29b7dc98bbd2fbc419
2.6.15.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 85062656e24b616f57463560db8a1a66 344b3f432d1bcc853da1f11b7fe83561
2.6.15.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 58d659ef350b6fa9d4a27a289c7f03fa 14c601838dafa97dc9c1944da2741ef4
2.6.15.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 104e212d4ffe20efacb44a2db0656aa1 fdebb0ac2d785c0ebf3e5e4989def0a7
2.6.15.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 15036fa9686a0485f84c6aa682c8af34 171da1d500ab72ba47bb830ebd129e98
2.6.15.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9e372e909c237e537321ca313965811c f788ca2f533b6df65383d9ccaefca225
2.6.16 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e53c27720acee3b64fc10c0ad8d377a3 50695965725367f39007023feac5e256
2.6.16.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3cd78c8412841b6b1ccf246e7bc9f933 51f7ce9d2206c9483cecc1ddfe020e8e
2.6.16.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 09fb4fce784e09d4575aeb701a5f81a2 ed5211dbddc3d2ec3fe7ceba93b8f3c0
2.6.16.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 61292bd2afcdd695aa72f9007681de61 11fae8344ed75b915347f44363ff4148
2.6.16.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8ee3f50d21ccace595dffe58513f68e8 7fbda643e9b81dd5663f3c780d873aac
2.6.16.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 918b457de742485c5f508314fde78a24 9bc201e9e0153365f5f63d0b94a921ed
2.6.16.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0737c9c3d87d07e8837b77f091edc502 1a0d4faaa51e5eabeebff3ddda3d1837
2.6.16.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f4be3eb6fffb1168af41c78ff2f99071 f523449a045710dd1e4da04895a8f000
2.6.16.8 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 92806f840fddc9ab5768d595d3e352fe 26a90f42900e8aed368f155367128c7b
2.6.16.9 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f3587bea8e2da0a6b67653c980683d7a 53207b81f5fceccc3ee2b4dcd663be94
2.6.16.10 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4ddbc90592f131b17b237e8887fe65fb 2d6d2d5c43fa2c364fffba06205eed9a
2.6.16.11 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 98dfc9b771c9db10909484a781d40e8b 4e1454a3ee75e6112d74ba9faa91986c
2.6.16.12 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d4a430a76d9c8102ebc79c60e062a253 582a768169afb9a45f29895d86bd439e
2.6.16.13 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f2abe5ce6691b781af3be894b985732e 54d5ccce923bf67bf76a1bbd72a409f4
2.6.16.14 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4db2da1881b5b23cd8edb395defa27c2 f454df464fd8f0c4a71b50ef55921679
2.6.16.15 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 893b765dc02209a77e064d963a236c72 c7be68856faee83084ec9ff730f021fa
2.6.16.16 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9d73f2a7c86ec3d5b2443f8842569415 6b17c4b73e32a60092e87cf223b0fe0c
2.6.16.17 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 653d42331c3c242c06899cc699578115 730a6267bed2845a4ca41008d4ad4f28
2.6.16.18 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9941a35299816326a2e56d3167a43f0a 1e9cc3c5b419fdbd92385fca1031ffac
2.6.16.19 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fd2b44e8877ca4adb776175fed981e00 318b60c5851f4d5a0a2911f4796bd96c
2.6.16.20 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0ea4c0c8ace3da39c28a2125b99ce4ee 46f4386dc5b0cf5fdbd3344ff745e351
2.6.16.21 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c34aea20cd263b50537c902ec8fcf3c4 04518cd185013e3f2616d4785f1d691f
2.6.16.22 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fbb6fa23634c3ecbd53f0905a5d6ced0 a0252f453e0b94e6dd4ade36f8e957eb
2.6.16.23 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 17235eb4b092924ae1e4e411e24e30c9 aae2e26b7737a641a5e39790de423601
2.6.16.24 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2ddc69d687e87ce1f3fff59bf6487443 3e5f3bac6a02920c96cc13705135f176
2.6.16.25 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx acf15c7189bf83089b778e8bcaa53371 7d5d484397392a413c9e0cfa373fd90a
2.6.16.26 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 061f38240cb4465a33c08ec678e6e1d0 30e64749aa292414a30e281276763a4c
2.6.16.27 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eae7fa6cebd25129aeb036ae53606931 38e0b035137d7a50f672005c7b445e71
2.6.16.28 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1637cf0ea3820166e4ccfd8576679ac4 06cfc319751d5d4c5efd7cc58d08e877
2.6.16.29 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4424d11ae548cffb550119d4c40543b1 589ed3abde57af7ba0761b74c0e2068c
2.6.16.30 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e54ee761cdc9df4447510141d03fb78d 48fc20d86fad36fc8ecea7827c8f8308
2.6.16.31 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 51452567b0bdffb973b3a25599ad870a b060b31b1553bd0f4899f919bc75c101
2.6.16.32 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 98093b4b3f6e57c8b227c733b98a9ad6 dd5f65278012c6e0b335ca3892a30997
2.6.16.33 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 38ba91f191eefcf2a6d038cd374812e7 47f50c1cf16a7aeb977f9cfffff9eee1
2.6.16.34 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a0ae34be62515f1257e32e7008a88871 a22c4301e6d1796b8454509e31525ee9
2.6.16.35 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f50ae18066b2684f6ea11f970039ec6a 2600c6130008afcae818ab9e095207e7
2.6.16.36 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f3692397cd3586e56f9f5151b33b8620 7abac83f300c493b9513bb7dfc00b040
2.6.16.37 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 64c43e3cbf9d31e8d7ad272db1463a1f a57838e4ecd6ecb7e64fdec18829e17d
2.6.16.38 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fdb2ab6866ebd6dff042c1d9aa01751d ca100ed2fe6199f274656702ecc03dbf
2.6.16.39 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ee3e5b3193a69fffd8347bdf413c5cf6 d552b34038a680a6bd90e0b79ad433ca
2.6.16.40 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e77c3d4f66df6458217e4dc47b4d2313 dedfe569626664f99e97ff7de5098fb9
2.6.16.41 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4d6f616d41d2fc0c1715b21e2b84d1be 2ae13e241821514e460a2b643f75b499
2.6.16.42 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 55eaa70ab3b5b2cccb968b15e69e9d52 4e0c9eaebd041f43924d8c4a6b3df43c
2.6.16.43 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3769304f6058796a56e20ab8407e6846 a18293482bbe59f89a68b0b52ca03ef9
2.6.16.44 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f1082d194bebec928837f9aff1451e0b c7f4a9003163009ad288b9b0fc752db0
2.6.16.45 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e09dcf0597149a4a191e3e5f5fac8d62 03fdf51f5f9e79e2b03630e5160fc254
2.6.16.46 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9be83fb732d626e93662e12d1383e01f a1f61fc4989b979460922d06893aba2e
2.6.16.47 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 32d09b699c7b370a2528122dc25feefc 1cae98732d1337c72f5c9f6f94fc1820
2.6.16.48 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f661ed4d436ae4814c36e86672b487c3 ad574b297d493ff29eb28959b50ab250
2.6.16.49 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx dfee9ff61e6900db6d3c0bda83251420 a0ba0081813721163143bd6f751664f6
2.6.16.50 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 219c23a215e72060cc1ecc2ae3d5e6bd 29d67ef797918d787c99cfb86cabbbe5
2.6.16.51 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ca1cb3f3318444aaf0a2fb8750d4ce67 49dc39e7e13718c9da014c12b0f4c86a
2.6.16.52 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1d81e44a2f617025755b1612fa590df5 ab4c67469172858a7ffbdcd7dd52b77e
2.6.16.53 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 73411eea5a3ee1413e1d9536179ae0e0 f3eb93808b76a527ac8c3527d868a9b5
2.6.16.54 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 13a499be8c6696118435e07873bd7d1f c017c3d7b22c062b8be5937a50180933
2.6.16.55 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 08f48e58130e2893f236d7fbf613c2e2 48184b5ad63a9d9ceef80dea1c88db9f
2.6.16.56 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 33645decda14080d81a9f7102a3a9c98 7eda8b474155c8e68f441c4348d0d57d
2.6.16.57 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e282c0992feab273bcb2519e7eb2a117 db92df5e0b54431ab88555bd7a4326ca
2.6.16.58 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5d3376fb90484d6ca7986462a6089195 bc6cc7d08b521ca4da71f06b5ec74073
2.6.16.59 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b5717d5c10760b1da2acef53e7748be3 d3f4995f26b06030ce4a0362d0eaf645
2.6.16.60 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 92426ba59ff88c2e0ce7746cff8a8399 6a94e7a89b622cadb4c1fe6fc86fafa5
2.6.16.61 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f1cf5204b63d1f6182e5988215dd6286 ffec9c0df8273547d1209183fdc64a81
2.6.16.62 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ecca3790043699f681a708e475c2c3ef a90828ab516f8f1ef1b9afede76baa4a
2.6.17 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e9bc6b98374a3a05d6ed81f3a9cfd72e 3ee4dae7b648e9c290f16fcfb368dbb0
2.6.17.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 533ba20ac908e0238399da293f48dd54 28e927078c6c7e7437bf7e02bf7586bb
2.6.17.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 14a2ef0b72f9e45d868542e5eab58e8e 96c979b9c353032072c3d612f3a6e533
2.6.17.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 082c624894951abd65fdeeced087d962 086e35843037da099900e5e5575d0aaa
2.6.17.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 50b80dde882295df16f7471fff48380b d0d78b8b9e9e1a7f250ba1fc39a3959d
2.6.17.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8c15c132ae154db002a63e71c3e6bd56 664fb2aa1bdcf22ea436ea6558277b9a
2.6.17.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aaf65bd8d23aabdf75ddd406a9646bc6 f0220345b7b0426d2f088c2f2cd294c1
2.6.17.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ecda5cbbe914f94d2bed8848ae9a4968 5a06690dd5663eae2907b61590c5c703
2.6.17.8 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 27e3048e504c7f76f221542b7aa90e71 6d4a92263e2a7c981229bb9b79c35215
2.6.17.9 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4fa552b025c43675d7f78cd377281daa f0709af5163d1862fdd9c2e0a806bc81
2.6.17.10 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d2ded9e14f0de702b5af8a3a7ae7106c 7b283d099d5149d81a32040c91eae6d7
2.6.17.11 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 28425b5d774d23a213858763dce32b0c 691637e82c46321322c9d0e9683afb6d
2.6.17.12 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 23c1449971ba8dcbcac6e6756609de11 33755004fb8ff86a5780b12ba731e032
2.6.17.13 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6fd82a0680b10b55d29cb3430c3b3b91 3a82892b0aed02d60bbd43bbc25c345f
2.6.17.14 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 242b1f18c6f0f569515da596e5b95de1 55473011ddeba627623a2e79eae51478
2.6.18 022 git git fa24e3245d8cb475ebffba763912063c ad43dd75219d9e6a8a9460bbf5f65b3e bc483723670bda09198d72293e712d42
2.6.18.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 387e945caaf4ffc07f53259f7dc11d72 c06781ec858300b6075a98a6dd075296
2.6.18.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a5d03c75d8abae325a709fd17f670a98 33deb7218df7d4407b562a2a08ba56ae
2.6.18.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 301f0e1f08d1f055230f5fefd183d84c 6357a0844ac055f63c52f6b726d6d13c
2.6.18.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aad664fe67f3bc95be6335bf7209380a e2c672cf071c75c8bebd5f599e6a07fb
2.6.18.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8bb3b1c18f7a4da706fb59b550d99df9 a03655c1bb317c54b448ece6cecc67b2
2.6.18.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fdd56a2874cf75a87061a7835e3657f3 76d0c0656a470498d58a4b1fe228b9c8
2.6.18.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 369610db40fc895b615b3995709051fc 1ed8fd27be96085e1b0047d3773fdd9a
2.6.18.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 519f4e1301abd30ff02e1e4c46cf5cc4 8f0e54c3afec1421e743a35f5a07addd
2.6.19 022 git git 2630dcec21807a23b8f3c1d3463a9537 be8a46187734cdb911bb4aa37f864f5a 267a9479c6c6a79a0b2f511ddcc17147
2.6.19.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bfffe69dabc04e2d6a7424be578cb5e4 636e33097b22f6d57de5c7e0a8394d12
2.6.19.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c0e23fc100d216497e274e0623640495 ca51612e0055bece7e1b016dede1cfba
2.6.19.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fe29f6e16d8708b2cba2f0e457cef093 1e0532b214dfbd841d66ecb57b17c281
2.6.19.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2fea910d90d6f8be6b1d43378f6edf64 33290887f0854cedf180e8ff07afe133
2.6.19.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d09e08774b337128e440e05ceeceae1c 3f436ebe67bc5ce9f5f8f2aaaf43697d
2.6.19.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eb845873b0f7ed3c3517daeb5967e19d 91bb72c73ee1f004511e06e9d2181139
2.6.19.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b7ce869b1fb9a60322b164a03c8cf388 453585d5cee3b534887ed6c1e5fe9590
2.6.20 022 root root 1c3a2b5f69f773e1ce3f02b0f3abddfa 1c3a2b5f69f773e1ce3f02b0f3abddfa 38b0d6ac20164a53cdab54f0039aeaf7 GOOD
2.6.20.1 002 root root c550ea5cee783951006450caa3dd3f95 c550ea5cee783951006450caa3dd3f95 8de9e67a66fd6e32623be16bff67866f GOOD
2.6.20.2 002 root root 61056db1f9194d0a153ece9572200b4a 61056db1f9194d0a153ece9572200b4a 24a8bfbc022ebf729a6fde2d399bbbc4 GOOD
2.6.20.3 002 root root 32820a679e81cdeb454f54d0994cf968 32820a679e81cdeb454f54d0994cf968 ed5a2b5870e5259535c46fe2b51a59d2 GOOD
2.6.20.4 002 root root dda6d62ecfcfd5d0f2d7ae9bd1107b6b dda6d62ecfcfd5d0f2d7ae9bd1107b6b 50588c7d6273ad481fdd26fa9ce25f9d GOOD
2.6.20.5 002 root root c39381da208d5c15a2710673df5654fc c39381da208d5c15a2710673df5654fc ff77928d030af8200ad48d90e249b8cc GOOD
2.6.20.6 022 git git 4300abbeb91cc50b48c086c2c329eab8 a4acbfe6fc54823d96dc257a2595257f fdd2e0336ec063cb8f6a4f36b0a3d257
2.6.20.7 002 root root 4352dedea3918d2c7d3a059bb00aa580 4352dedea3918d2c7d3a059bb00aa580 429632d5efc6c90759c301652cddcc58 GOOD
2.6.20.8 002 root root b26f5458b175e3b935586c433aa82c8d b26f5458b175e3b935586c433aa82c8d 04ecc74a2ed79afd267c9c07755ba74a GOOD
2.6.20.9 002 root root 12bf096a9ec27317a7fd0bf5241aa86d 12bf096a9ec27317a7fd0bf5241aa86d 125778f04354ac2e745499b58cf7d6ba GOOD
2.6.20.10 002 root root 3865227516b1ed115dcf52eda4ff1ad8 3865227516b1ed115dcf52eda4ff1ad8 689ce2cb0737cd95826fc7126c70626a GOOD
2.6.20.11 002 root root 235e4c9dda5c423ac3ccd3aee7587553 235e4c9dda5c423ac3ccd3aee7587553 0f6a91c70002e2cfd0c0a6ce17444d8b GOOD
2.6.20.12 002 root root 8d9cc27403c29355549998b7966d6350 8d9cc27403c29355549998b7966d6350 02713c1f806436dba157c15e8b8802e2 GOOD
2.6.20.13 002 root root 7331349a0e0fe5dbd230fb10900846f4 7331349a0e0fe5dbd230fb10900846f4 5d79938dd836d09ad3a5d158e374cf8a GOOD
2.6.20.14 002 root root 8e7be87759f3ead0852137e366c34a90 8e7be87759f3ead0852137e366c34a90 291ef875f6787af051ee943134443cb2 GOOD
2.6.20.15 002 root root 7bad3d284c2cbbaed0d2338f81e76859 7bad3d284c2cbbaed0d2338f81e76859 e3ce8fc41c019a0baa05e0b8318745dd GOOD
2.6.20.16 002 root root 25a1013fabd489d302f71bf3cb1837b3 25a1013fabd489d302f71bf3cb1837b3 e9c78f6182b83f68b0f654ed6837ce5d GOOD
2.6.20.17 002 root root 5259b132a710eacc1e7489129f3b9e0f 5259b132a710eacc1e7489129f3b9e0f de390b611f39658ab89c8b519b0daf97 GOOD
2.6.20.18 002 root root 4af3439c081f86b68a30d0bd447179c3 4af3439c081f86b68a30d0bd447179c3 e7189e95ef81cae9eb8b65d4aa828e98 GOOD
2.6.20.19 002 root root 8bee08600da3f46bce0d2f15b1e3b68e 8bee08600da3f46bce0d2f15b1e3b68e facb801a1653ec6a8b856032d1f03a1a GOOD
2.6.20.20 002 root root eb1b62690aa859f6d1deb70695e253a0 eb1b62690aa859f6d1deb70695e253a0 d9c84f85036c1d8745661485d484d61f GOOD
2.6.20.21 002 root root f85b1a1337f825832d1b39d1c62f457f f85b1a1337f825832d1b39d1c62f457f ecb03f520bb06be2d01b2e6258e2d346 GOOD
2.6.21 022 root root 7965f0be6b6c1a4ff4e34336ba25d975 7965f0be6b6c1a4ff4e34336ba25d975 76eb5308dfc7d9ab70534378af379c09 GOOD
2.6.21.1 002 root root c081d29d0c6ff1b61fd962b8259ecbc6 c081d29d0c6ff1b61fd962b8259ecbc6 c1e64db8f384a00c19e9a23d0401cadc GOOD
2.6.21.2 002 root root 78d892b513b1b323ad12e3d3c69f6dbb 78d892b513b1b323ad12e3d3c69f6dbb 862039fcc0a679bd7e387cccda47e5d9 GOOD
2.6.21.3 002 root root 26b27b1aacaac870c94c3ce14155489c 26b27b1aacaac870c94c3ce14155489c c7815d473e630780ab10c582c7809c0e GOOD
2.6.21.4 002 root root 562dbfe628d7f4ec5be02f2eee444209 562dbfe628d7f4ec5be02f2eee444209 82cca4d22dd920c2f22159e5c3d7f4e6 GOOD
2.6.21.5 002 root root 4c778ee298cba1ba82d8f8ec00959f3d 4c778ee298cba1ba82d8f8ec00959f3d 227d5508dc23bc487d0a5248e690fbb1 GOOD
2.6.21.6 002 root root 3fc9cbc5f1eabdb79f0f819785aa79ee 3fc9cbc5f1eabdb79f0f819785aa79ee 51cc7a0f3fdda8aa1c510791c5bc152e GOOD
2.6.21.7 002 root root d4efe4b192ca2be608b75a881ebca902 d4efe4b192ca2be608b75a881ebca902 66344cad74e92c6226bea32215816ab4 GOOD
2.6.22 022 root root 2edfd190ac09c0e5b998ab8514488cfa 2edfd190ac09c0e5b998ab8514488cfa c98e1329975a8a7931ae63bafe39b63a GOOD
2.6.22.1 002 root root 93e4955063c604799affa171cb6370d4 93e4955063c604799affa171cb6370d4 1ed7fa45fd8ac8faf19f5f48dbe54e9c GOOD
2.6.22.2 002 root root 5af3437e6ff97f9920d227681f1c7b5e 5af3437e6ff97f9920d227681f1c7b5e 296d36f688f82dff934a98e05e1dc5fe GOOD
2.6.22.3 002 root root 65e5a5d73e732ef3657554b2eeeb3547 65e5a5d73e732ef3657554b2eeeb3547 54dc78c7d23e3e2272ec15b8caa3307f GOOD
2.6.22.4 002 root root d2294a1e23ef416c0b03cfb84acccd3f d2294a1e23ef416c0b03cfb84acccd3f 1b57bf74df8ee5b2078a33c41fe578f5 GOOD
2.6.22.5 002 root root 34bfb927e95b7645ecace1becf492b09 34bfb927e95b7645ecace1becf492b09 5077c04dfe5aa3c55e5b77e13a0b2e23 GOOD
2.6.22.6 002 root root a610d656962ebfbd46efd96ce0a96c66 a610d656962ebfbd46efd96ce0a96c66 155cf629abc4215744c711f0773fefba GOOD
2.6.22.7 002 root root d89f77ec176b0eab0be04ecdd06c1a2f d89f77ec176b0eab0be04ecdd06c1a2f ff8d5fa0f97e5f39e3ad3f95b3b18365 GOOD
2.6.22.8 002 root root 3b49a858cd506f320fa24adcec47c8ab 3b49a858cd506f320fa24adcec47c8ab 0fbfc23579850a8869fd2d98671bf5d3 GOOD
2.6.22.9 002 root root db2827199bfa42595a25bdad5e6fe500 db2827199bfa42595a25bdad5e6fe500 c23aef37928a4167ccc0cdf4ffb2d6b7 GOOD
2.6.22.10 002 root root 2dc8fd7f16668e1997a74a1e731febe6 2dc8fd7f16668e1997a74a1e731febe6 c4f54241f11bb4b9067ca78036dcaae5 GOOD
2.6.22.11 002 root root 57eb4df5f3863be6c6be405eb8a97c1a 57eb4df5f3863be6c6be405eb8a97c1a bb72d4eb74bbb1b77f121e43cf9a2c50 GOOD
2.6.22.12 002 root root 055c7b258abb9489dbced86537c7dc4e 055c7b258abb9489dbced86537c7dc4e 6fb1dc14cf4e432fc8ab208bb532cee4 GOOD
2.6.22.13 002 root root c1f411391548652149ea78afd7ffd026 c1f411391548652149ea78afd7ffd026 eb1d0f88827dd076df6ed2c8c3dbe670 GOOD
2.6.22.14 002 root root ee15acfef4c0e9b787816546129c34a8 ee15acfef4c0e9b787816546129c34a8 cb29d02fdde2d7c3fe1337d94d629753 GOOD
2.6.22.15 002 root root 159067c422109e1b56e43fdf34e049f7 159067c422109e1b56e43fdf34e049f7 d66f9c0b68ec9e8001dd98d262dc7c15 GOOD
2.6.22.16 002 root root cf84f4aca3f11062968b5ce2351560c3 cf84f4aca3f11062968b5ce2351560c3 006ce66ee6763320f1309f29bfb1cae2 GOOD
2.6.22.17 002 root root 18a6b5c1759d2ed3d2552767d76329a0 18a6b5c1759d2ed3d2552767d76329a0 856368e29051f667b573b5377c410fa3 GOOD
2.6.22.18 002 root root b64d9b8f3c050692538ec941cc6ffd2c b64d9b8f3c050692538ec941cc6ffd2c 7ce91fc94a08dcca16997313f3af7ec4 GOOD
2.6.22.19 002 root root 5d5f55c4a794af96dfb7de2114755bba 5d5f55c4a794af96dfb7de2114755bba 99f756bbbc303b7e75eced5116b916bc GOOD
2.6.23 022 root root 853c87de6fe51e57a0b10eb4dbb12113 853c87de6fe51e57a0b10eb4dbb12113 46434575a50b8d93ec04fae80fc5e890 GOOD
2.6.23.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e0fdc51eab8cd05095a79933b1f7dd67 13406ba7dfd3d9ffb6efdea03336d0c4
2.6.23.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7d8932c757e420c8d5e50f1be9c2411e c54bc9c3fe525ba3315db1cdf790ddbc
2.6.23.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b36557355d75131f193df548978a1ee1 de3ad48cb264e06c7c2fe7b02cb83f7b
2.6.23.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c3c0824b2c0e1b468eb4866edddc09ff 79f1de0679903f433f2844538e3ccfbb
2.6.23.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4630320a2c99bac78c2af3324ce33117 3d3de47b19f46dc01e1e449935edaf31
2.6.23.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a01191548f580df59157cf273dcbe607 90a759bc2f04b8e5e8e306784c113e78
2.6.23.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 531e7bb89441309e2a79106bfc28dfbf 35d83826fcf45820ffa678f2eda3cac9
2.6.23.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7ad20e137963543c46f4402c79accb1b 7b591da5db63cf9910c0eea6a79cbd3a
2.6.23.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 07c1c75a34bf2cb2517dce78491c2236 dd6d45e2b8d965cd013647ebf3b97f6d
2.6.23.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ac0da020542a014f8339bd85f520db65 6ec1ee797f5b6bb5f7cddae932df372f
2.6.23.11 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d1807eb886104772ec5721b401d04171 b33625c16a5fe6f29273b4a3fefb0e17
2.6.23.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e509962afd2040b4a9dcb88e8dac2d93 527918effc9b8a40b5b15219091d3330
2.6.23.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f70e0e9215c751238945e0d65f0bedc6 536b1e209bfe0211928df53e92b577e6
2.6.23.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 81d2f44218efa76b849f8d874109395d 763b59f98bf021f2766de996f819d5f2
2.6.23.15 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 17b289e417f49cfcb9212d0e8f00ce0b eb0fec1f46afebb2454d2dcf222aa0bf
2.6.23.16 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 14d58be1fdcccb7456eecb887be9e0f8 d87f8215080c53d5403eb26dc99d3242
2.6.23.17 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 09c584d8c89f07468703b6a7eeefe147 f36af6492489b0ca8b7ba13ded8872a6
2.6.24 022 root root 19aee46bdd4577a4ba14ba51284cf791 19aee46bdd4577a4ba14ba51284cf791 f09806748f6809d5f7d2a1859240e1a5 GOOD
2.6.24.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fd5d1ca4b097581b7ee67a98212d210e 83e184f27ae53ea14e841af0344e6d85
2.6.24.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cef2840c958447ef2e00dbdcb638ba17 e4aad2f8c445505cbbfa92864f5941ab
2.6.24.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 75cd7750aad7787a1c646988b717da74 facf544191ca836a309ee960eda3a80d
2.6.24.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fc2c8bc930292b6d3ba164374bf65c98 71093ee1daa3e0843b48492d54113f33
2.6.24.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c434ef910d81ab954e212f82d89ede63 21360e644d0feeb259793f86b7295f0b
2.6.24.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3abb0224ab760b595b86822d0436c237 eedd24c3642f0788a742e1b996119fda
2.6.24.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6305363b40d4e2d44c468133c8290f99 30f254a65227fe388aff8abfe8456a1b
2.6.25 022 root root 2b8b848fcae4e1d4fb56c897e3a40c21 2b8b848fcae4e1d4fb56c897e3a40c21 49365ebfea0d5d216f4da597c3e28f9f GOOD
2.6.25.1 002 root root ca288f8d0a47a31a2007da996212dace ca288f8d0a47a31a2007da996212dace c83890a56cac5e49ad2acba50f3c737f GOOD
2.6.25.2 002 root root 5199cfe55c13162661ec4035272e072d 5199cfe55c13162661ec4035272e072d 23148e8640d9dc48bbead012eff4244b GOOD
2.6.25.3 002 root root 5857b5bb21fe8d41460e89b87b9f5362 5857b5bb21fe8d41460e89b87b9f5362 049eeb232ff9a2e239f2029b91bf8476 GOOD
2.6.25.4 002 root root e64c0ae28293e0c578a029af170150d2 e64c0ae28293e0c578a029af170150d2 b7509c03baf2d842556765eb19982d6f GOOD
2.6.25.5 002 root root 828cad924870acb9643bf4bb0f72cc92 828cad924870acb9643bf4bb0f72cc92 dade9663f31ffe08c36271132835a004 GOOD
2.6.25.6 002 root root 6e0ee8c95c9aa2b619dd9159c1eab57d 6e0ee8c95c9aa2b619dd9159c1eab57d 98500db8178718c51ed6b242d9b1ed6c GOOD
2.6.25.7 002 root root 9ccdda12b747a122a94ac30e735ba9f9 9ccdda12b747a122a94ac30e735ba9f9 9a716afe867443cf2ea20d425a79a7f6 GOOD
2.6.25.8 002 root root b1adac6690deea86340d5e18fd7bee7c b1adac6690deea86340d5e18fd7bee7c 3d9fd797d68e5786236a817200439833 GOOD
2.6.25.9 002 root root b737d23e536e7f9bd93a5888656c6a87 b737d23e536e7f9bd93a5888656c6a87 6efa1677d919a341d2fc6e65df306976 GOOD
2.6.25.10 002 root root 29fbcbf3fa504b000e6b405c681e91eb 29fbcbf3fa504b000e6b405c681e91eb 0645ab9c54b04ff11d09a949432cabec GOOD
2.6.25.11 002 root root 225c43654b864c303822385572e8df9d 225c43654b864c303822385572e8df9d cfdb2fdee18d1801939e995da01df804 GOOD
2.6.25.12 002 root root f5d46c6ae6d2a97f8d54610d8a71665b f5d46c6ae6d2a97f8d54610d8a71665b bd25fe05a9a67f0208a2bae486fa5cac GOOD
2.6.25.13 002 root root d2affb4524db60f4e0c8c79a01fc565b d2affb4524db60f4e0c8c79a01fc565b de9e88a477558d163b0d9f21ba709880 GOOD
2.6.25.14 002 root root 39380a57e0d2826acc72e16e0d0bbe86 39380a57e0d2826acc72e16e0d0bbe86 2e64c858b2dd1fb276ee752040ed75e7 GOOD
2.6.25.15 002 root root 32c56b46350368ca97f0afc4dc291e4d 32c56b46350368ca97f0afc4dc291e4d bb916acc0e753c9f70cf65355e234049 GOOD
2.6.25.16 002 root root 9701b00fedc1d674db536adc5e5ddf11 9701b00fedc1d674db536adc5e5ddf11 ac004c3dff696d484c31b029d9793020 GOOD
2.6.25.17 002 root root 47b63e5d2f59ea4f945fc954ef4aac29 47b63e5d2f59ea4f945fc954ef4aac29 1f9c9421eb0e7513df5c0bc9802800eb GOOD
2.6.25.18 002 root root a26142b7c3b02860bc1bb2eddaf621e3 a26142b7c3b02860bc1bb2eddaf621e3 290621fad638dc3d9ba48fe6585eee27 GOOD
2.6.25.19 002 root root 78273a08ffe44e3a85a0574e7d67f367 78273a08ffe44e3a85a0574e7d67f367 05b9140207be21a9b67ff669df1c42bc GOOD
2.6.25.20 002 root root 6eea4d0acd22b88c124ce2dfe70a716a 6eea4d0acd22b88c124ce2dfe70a716a 696eefcb16debacfff616b999e7298da GOOD
2.6.26 022 root root 75aa7264f67777b0adf16bb38b2b90fa 75aa7264f67777b0adf16bb38b2b90fa 5d5fe5d6203faa60fa8fbf03e8af20b5 GOOD
2.6.26.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3a62319934f36c477ea3d8bb053f6537 0061950ce2810d05a4d5417b782bc29d
2.6.26.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 78a4296cee5ef15932e893a314982c6f 0ed153e3ece78823ccc3976e7458d6ea
2.6.26.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8d213371ed5147378f4c26923d8b6129 ed0d8efe5f6c5dad54f18b015734f767
2.6.26.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7bc3eb65a67450cbc1a0fc52543d2eb1 15aca687f44a14635d9d3f18156c4bc0
2.6.26.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2c3d31c1e98b4a36ed84439a20837ec9 35806a7e00adf0121fca21a5c3c35143
2.6.26.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 59aa2ef47641c64191af3c2405b70f4e 752fd397d8fa65fe26a73bf0dd250bca
2.6.26.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 90320b312a431786e0d2d64d09c0d5c9 79d2648d6e712495e8b3d9af42ca0a5d
2.6.26.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bf0e9438e320f93d3ea687db9958a786 f6f632ab5de96f45f822b596a43e516a
2.6.27 022 root root f9fb49f756036a34d26eee85240ff8fb f9fb49f756036a34d26eee85240ff8fb 482b04f680ce6676114ccfaaf8f66a55 GOOD
2.6.27.1 002 root root b02d388a1b5179fd40139bdc6d5a2ccd b02d388a1b5179fd40139bdc6d5a2ccd 16f3702145fe1086379456c5450beeb8 GOOD
2.6.27.2 002 root root 104577a9cb43ee17832e6079a05bb37d 104577a9cb43ee17832e6079a05bb37d 4e3e7fcb39f06672560da7ea364787cf GOOD
2.6.27.3 002 root root 88b3887f45666600820778d4d10d4d86 88b3887f45666600820778d4d10d4d86 45cd5c183f7e391ffc70ecffbac1c885 GOOD
2.6.27.4 002 root root dbb8b8b58962acf4945a5d73810330d6 dbb8b8b58962acf4945a5d73810330d6 d81f0b3248fedbd04d64b36bd29d3b50 GOOD
2.6.27.5 002 root root 99b5eb960d4709d8eab162696d7601dd 99b5eb960d4709d8eab162696d7601dd 1e08dcb0bdcafa156de5a4d4f32a43f7 GOOD
2.6.27.6 002 root root 921927e2cce7f3e59c4f76d54c77ffcb 921927e2cce7f3e59c4f76d54c77ffcb abb0e4a7d19d65516fb3955fcafd4434 GOOD
2.6.27.7 002 root root da79852b3b31b665ddac1eaff1712747 da79852b3b31b665ddac1eaff1712747 d5ec2c2c0ab942d4c8ba3befec5441a7 GOOD
2.6.27.8 002 root root 10b609f0af0a4fcf0ed18e2d076d8310 10b609f0af0a4fcf0ed18e2d076d8310 acbf27c894734fb7e8f106dd070afd88 GOOD
2.6.27.9 002 root root b62bfd7ba8a13833440abb458267c8cd b62bfd7ba8a13833440abb458267c8cd d85afbc652b42e433ba3193f0cccb46f GOOD
2.6.27.10 002 root root 18abcd2d7d157c1cb02bc77f9c2834e7 18abcd2d7d157c1cb02bc77f9c2834e7 d4fe287fc90837eb49e525db7208d543 GOOD
2.6.27.11 002 root root 38c7b9727f34961d25471cf3962079fd 38c7b9727f34961d25471cf3962079fd 1c1f634c5c391a344e1be0aed106f9e9 GOOD
2.6.27.12 002 root root 54f8917ddd5b8c0b89e58aa348a725f0 54f8917ddd5b8c0b89e58aa348a725f0 3840920620f7db785494457b1ce5d6b6 GOOD
2.6.27.13 002 root root 18dfed96ccf2ca4874953d5a2618ab63 18dfed96ccf2ca4874953d5a2618ab63 587cd2abd05749c05ad56ac45cc4d119 GOOD
2.6.27.14 002 root root b8721dbdace184d588d68dc5639feb9c b8721dbdace184d588d68dc5639feb9c 0fe6d26c7cd2a8562b5e5c8b5554556e GOOD
2.6.27.15 002 root root c7e39c082d49e20cf5da354e3e603214 c7e39c082d49e20cf5da354e3e603214 6f41b442780cb4a825fd57dd9358cbaf GOOD
2.6.27.16 002 root root 81462897e5ddab2c09f79f9c58c6bacf 81462897e5ddab2c09f79f9c58c6bacf 3eb3b891fb008225ed4697fe16ebebf6 GOOD
2.6.27.17 002 root root 5a03443dcef39fc7b6afa3d7ab9e22b4 5a03443dcef39fc7b6afa3d7ab9e22b4 648643f873e6a8d197bdc1d7b2be07e1 GOOD
2.6.27.18 002 root root 8e272f65bf0c7dc73c57d85dc6c75b9f 8e272f65bf0c7dc73c57d85dc6c75b9f 4f8983842de76f07174eda5e72d2ee30 GOOD
2.6.27.19 002 root root 61e60b5c2fe91f28da019a078be8d0a5 61e60b5c2fe91f28da019a078be8d0a5 3dea19468d572ab355fb48d4671769c5 GOOD
2.6.27.20 002 root root 8324c79cc242afdfe86f1e5964e49d60 8324c79cc242afdfe86f1e5964e49d60 b5ae12dc14dbaebcf29d5e08e6739a5b GOOD
2.6.27.21 002 root root 13a0e7ca645dcc462a2c0f4e265a6760 13a0e7ca645dcc462a2c0f4e265a6760 28a2d38a7f1a5adaeeecdd6551af276a GOOD
2.6.27.22 002 root root 7f76aff66928dab42db7fd9c963b0813 7f76aff66928dab42db7fd9c963b0813 14d7dcf5533b2186064227a5580cf9c5 GOOD
2.6.27.23 002 root root 399cf04ceb5f05eddea8a9782cc2ddab 399cf04ceb5f05eddea8a9782cc2ddab f4b09805a0ffaa9b006cedfb5cad85e7 GOOD
2.6.27.24 002 root root 2cb77153d209a55367edc8398f4afa88 2cb77153d209a55367edc8398f4afa88 5e151df81e74fc992af3af3d43d43970 GOOD
2.6.27.25 002 root root bb963116a132b885f4902ddc1e561920 bb963116a132b885f4902ddc1e561920 404c9a0a6c9a54223a9c2b1f66be0bae GOOD
2.6.27.26 002 root root 0bf3c35f3807bdd95a3e74d691392afd 0bf3c35f3807bdd95a3e74d691392afd 15823c3469931b24c5d6ab331ac10bb2 GOOD
2.6.27.27 002 root root 3e4f73295dc177201ab546bcb360feae 3e4f73295dc177201ab546bcb360feae c70b796328e971e7b472320c1d66580c GOOD
2.6.27.28 002 root root e52c78805e8f44af814f9e76613e04b2 e52c78805e8f44af814f9e76613e04b2 003652f373b29da022a3f158c5b7273c GOOD
2.6.27.29 002 root root 5a7de732a819d219f51fe5b47f645555 5a7de732a819d219f51fe5b47f645555 514db1b159b00f4cd9fac94845780288 GOOD
2.6.27.30 002 root root a19b497d70fe55519e1fc158ce5afe0d a19b497d70fe55519e1fc158ce5afe0d f507ffe1095e18685567868814f0b400 GOOD
2.6.27.31 002 root root f5bd4a54000bbc19b319cd1c084c0b1a f5bd4a54000bbc19b319cd1c084c0b1a b11e975ba28cd8004c2e8d0671f84043 GOOD
2.6.27.32 002 root root 7321d15dcab7a704bf4bb78a0bc0c599 7321d15dcab7a704bf4bb78a0bc0c599 09b997cdb0732fa875f666df18471586 GOOD
2.6.27.33 002 root root 55fcebf49f18a06e24468d5b4b70dfd9 55fcebf49f18a06e24468d5b4b70dfd9 87dfac18a465cad12476253f348b1024 GOOD
2.6.27.34 002 root root 7d8eb3d81e947465a6c0deb52839b20b 7d8eb3d81e947465a6c0deb52839b20b e30a992713b46b49d2e5b7578370ce1f GOOD
2.6.27.35 002 root root 1289c724be385e99e89593ea39835ad9 1289c724be385e99e89593ea39835ad9 7a8b6e8a26afc82f585c04ec8c0b8cb4 GOOD
2.6.27.36 002 root root ee2a5457dcb337956bc03059fc92c2a1 ee2a5457dcb337956bc03059fc92c2a1 743588b4b5ece590484fc094952a88dd GOOD
2.6.27.37 002 root root e90869665b6e4860828c0f7097aaa513 e90869665b6e4860828c0f7097aaa513 8aadc962b0922dc02b4fafefc9320ccb GOOD
2.6.27.38 002 root root 763dbfd6558ce5dee3ae8ce720b2645c 763dbfd6558ce5dee3ae8ce720b2645c eaa5ffb8b82b6c43b936f5eef325705b GOOD
2.6.27.39 002 root root dc579c8445954eb512977b28224dfef9 dc579c8445954eb512977b28224dfef9 48c2af9882f88f50ef64a21c34b62376 GOOD
2.6.27.40 002 root root a75c56fb79c601fa6a8ee753672895ef a75c56fb79c601fa6a8ee753672895ef f140e426f5ae345b5252748852ebfdef GOOD
2.6.27.41 002 root root 832c145c0ad862d038b41c6a09e19e6f 832c145c0ad862d038b41c6a09e19e6f 4fba3a8b572e6eb613d80760fada12fc GOOD
2.6.27.42 002 root root 5df04b71553553d1e5833c65008425d5 5df04b71553553d1e5833c65008425d5 0babc187fe3f0420d7c5d6dbc5f5ef4a GOOD
2.6.27.43 002 root root 50b70a5f28747b070bdfd0bcc7f9529b 50b70a5f28747b070bdfd0bcc7f9529b da6c3fae5aa2d353044b9735cb914f38 GOOD
2.6.27.44 002 root root 07f9c9509becfdf6ddef4f142a2b87fd 07f9c9509becfdf6ddef4f142a2b87fd d7fa6cba565a4c03915eb7f6ac622610 GOOD
2.6.27.45 002 root root 5df8e25fcaaf9ec0b108c68d31c1f23a 5df8e25fcaaf9ec0b108c68d31c1f23a 0e63bce115697e4c12448c958266a6d0 GOOD
2.6.27.46 002 root root feb0c66e8af4e3c73bb7675ad99633cb feb0c66e8af4e3c73bb7675ad99633cb a37732465b3ffccc38a363d45634c098 GOOD
2.6.27.47 002 root root a10aedc65ec24f5b9f5e7d2534adf94e a10aedc65ec24f5b9f5e7d2534adf94e f0760a94c42906bf69497eb5d91745f6 GOOD
2.6.27.48 002 root root dab808dedf4eb7e1425cdb0b30a4c8cf dab808dedf4eb7e1425cdb0b30a4c8cf 68de870ad5458f9b17105ad1e5ef342f GOOD
2.6.27.49 002 root root d0ec0912960ab79e90d228da7fac1d67 d0ec0912960ab79e90d228da7fac1d67 9cd6bc8e911154d4cd47b0b0350bd245 GOOD
2.6.27.50 002 root root ce3e327c7291fe271340eaf2904a4347 ce3e327c7291fe271340eaf2904a4347 0237b80ec327334cc76dce743db529ce GOOD
2.6.27.51 002 root root 3256ec86d0249f6f0bf967718fd35363 3256ec86d0249f6f0bf967718fd35363 8dd26f17366188f282fbc8af0df2de29 GOOD
2.6.27.52 002 root root ed87ed7d7fce749a3faf845c85880ef9 ed87ed7d7fce749a3faf845c85880ef9 344edff782adf44dd23a59e4e00fe4be GOOD
2.6.27.53 002 root root 108d6b3f2c723bc4360e3bbbb2474aec 108d6b3f2c723bc4360e3bbbb2474aec 74cd04293010501839f464242f9cbf20 GOOD
2.6.27.54 002 root root cc203656605a40fca27f90e993952788 cc203656605a40fca27f90e993952788 eb7b06fa72c986757dec15043b89a6ee GOOD
2.6.27.55 002 root root 28b6bb904578f3bbc3dafe22b0f3512a 28b6bb904578f3bbc3dafe22b0f3512a b1874eba773004b4601aebf5467c54d8 GOOD
2.6.27.56 002 root root d135df3b77fe7c83ecc369139719085a d135df3b77fe7c83ecc369139719085a d3e6dc3a1fc0fc0ca613c90a257d702c GOOD
2.6.27.57 002 root root 8a6cc185e7c91835b12c85969a3f00f3 8a6cc185e7c91835b12c85969a3f00f3 ffe5edcaf2da6ced503f5ee8306478de GOOD
2.6.27.58 002 root root b9f88fc59a5b7dede53249eb1cf056d5 b9f88fc59a5b7dede53249eb1cf056d5 d4d5046ee9f0ae87886f1280b1dc6e98 GOOD
2.6.27.59 002 root root b13ed9fb91f415f16549da6b05cf0a55 b13ed9fb91f415f16549da6b05cf0a55 a9ec0caa367887f48b6ab157da6be804 GOOD
2.6.28 022 root root afb7b848123b8f2df42cf42f0845860f afb7b848123b8f2df42cf42f0845860f 062c29b626a55f09a65532538a6184d4 GOOD
2.6.28.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e310b48eb15e8897db9fd276822f3501 9677bf9cb0b8da192ac010f55d71dc36
2.6.28.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 763d014e941bfc574de13b8f2db495dc 5db081d864a28894f44c565949b97fff
2.6.28.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2d4c680841ac0c6bca914e8bb3203bd0 715c7ec7db9183d931f896785ef8aec0
2.6.28.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0023f9d52f13929fbc878e6c497d204b 19968a11ed6e19941fdc4cd97827b5ff
2.6.28.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 34be72201b4e707951f0af857b737be9 0cf4c46e70e19bff4d24d02786ba89ac
2.6.28.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f8d096f83f2d7ff1592244e37b122b04 4862fea65983bffaa62642f20ba1321b
2.6.28.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e77300a8e11b15c87074c54d81ae83b5 12a5c040fdce12aa5e3fd29f5e88f722
2.6.28.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f35ba388bb1f6f7bd8bea72eb22b0684 9f69cba9a2740b829cb09914960a51e9
2.6.28.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cacfadf15c10896956e3776e8f603e0e 863ac05e6a7dd0fb46a664b53306716b
2.6.28.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4c99456b1931d4f0d7f49f7d62d18431 8513345dce011467ff6067c92634c3e9
2.6.29 022 root root f614a023dd7a9b38303a35aebedb3a4d f614a023dd7a9b38303a35aebedb3a4d fbddd9081c55e4c2f99e48d0f2a269e1 GOOD
2.6.29.1 002 root root 3378af02af06b10b3725a7f90a1e2832 3378af02af06b10b3725a7f90a1e2832 b8c75fce19ab913d567ce2ceacbd1aa7 GOOD
2.6.29.2 002 root root df3f8999068ca47425826f97643a9b01 df3f8999068ca47425826f97643a9b01 4a6e3bb90f5e3c67a2f2af9039185402 GOOD
2.6.29.3 002 root root 0c32afeb514f2909950c10704ea1c251 0c32afeb514f2909950c10704ea1c251 9db11b204a6514d34f6cdedeaf02b513 GOOD
2.6.29.4 002 root root 3510ca1d830c8b9fcef92c258d0a4762 3510ca1d830c8b9fcef92c258d0a4762 9674b69a762c397ace6fc5e7096751f5 GOOD
2.6.29.5 002 root root cef8e5a3bbf183e7ad3281b1f3bfe657 cef8e5a3bbf183e7ad3281b1f3bfe657 a030d6b2c8e9e38534e9ca58f9f62f04 GOOD
2.6.29.6 002 root root 3d9def1cc78eac6271b54194434695e3 3d9def1cc78eac6271b54194434695e3 770efe7eb2d919eb1e794f78088b893c GOOD
2.6.30 022 root root 2bca7fef9e6aeaafcf4d34740c2a511e 2bca7fef9e6aeaafcf4d34740c2a511e 0f50954dc556d28b2b5719722f599380 GOOD
2.6.30.1 002 root root 1f57a5f8a65bd38e7b9c2f2c1ae32f66 1f57a5f8a65bd38e7b9c2f2c1ae32f66 d6eb48048ba5877d6486c70fb5accb46 GOOD
2.6.30.2 002 root root bbc68779259558afca403ca041b49073 bbc68779259558afca403ca041b49073 5294e6ebcc148e8db363cc08694b2724 GOOD
2.6.30.3 002 root root 6a5963823ecfc432f36827d5c17b9cd0 6a5963823ecfc432f36827d5c17b9cd0 9900f3ad5adeac73382300b86ef6c3d3 GOOD
2.6.30.4 002 root root 9a3533d3a716913fdf7f8b73f1beae45 9a3533d3a716913fdf7f8b73f1beae45 ad42fc4417bb0a130c769fbf0ba4221a GOOD
2.6.30.5 002 root root b446af3c919a4cf65008b61f75e88cd6 b446af3c919a4cf65008b61f75e88cd6 daea7f2a981260e82aec0fbfce466f5a GOOD
2.6.30.6 002 root root 4d87e17f3b3448ce7e69afc9debf0efd 4d87e17f3b3448ce7e69afc9debf0efd 59932afb4ab8ebc5525d69422988a00b GOOD
2.6.30.7 002 root root e5a18192355fc18831f83ad8338378f9 e5a18192355fc18831f83ad8338378f9 f85c1f970ac430d3c239bdf7ff4c72d9 GOOD
2.6.30.8 002 root root f6c70ebeaaa1e0f23cf4310bba9ac827 f6c70ebeaaa1e0f23cf4310bba9ac827 8ab4dc01676fea0e17dc30b2f94947e7 GOOD
2.6.30.9 002 root root 327a5876f9884ac4e2dd79b642790b4f 327a5876f9884ac4e2dd79b642790b4f 69e356027dc7c78190f7c70ae8b1d5d4 GOOD
2.6.30.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 135720e3d5cf72949a6e2c7b7a1661ac 9ef9dd7efee7d6831c770557222987e4
2.6.31 022 root root 153f6267e44f5d32a364aa61e2b8c537 153f6267e44f5d32a364aa61e2b8c537 16c0355d3612806ef87addf7c9f8c9f9 GOOD
2.6.31.1 002 root root 0697e50b0515da0c94700a56acaf84f1 0697e50b0515da0c94700a56acaf84f1 1ce57ad412b8497d2bb87728b22d244d GOOD
2.6.31.2 002 root root 4e5ee234f4d1ce8a2a97e81d1c3e5e3e 4e5ee234f4d1ce8a2a97e81d1c3e5e3e d7a47e2a6de48ec3831634d3868cc601 GOOD
2.6.31.3 002 root root f686666a2218afd13f2c6bc794919615 f686666a2218afd13f2c6bc794919615 19ba8cfdedeb2c59e299526472a2741e GOOD
2.6.31.4 002 root root e2e84fc3cea9293517698f2af02e3698 e2e84fc3cea9293517698f2af02e3698 1f8185cc6d3892ce3d51efb200a0c585 GOOD
2.6.31.5 002 root root a1518ae179af94eb840024655ed4471a a1518ae179af94eb840024655ed4471a cb58822f6046ae2ec13a3ee4bf13896e GOOD
2.6.31.6 002 root root 660348915031cc50ede9b6ae2028bf52 660348915031cc50ede9b6ae2028bf52 83323fd772d0e32e4c0c5e16542f9c6e GOOD
2.6.31.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c582645a702bc6a539c6487bd30395b0 b82342ff9af52e850ec839f1a9af5212
2.6.31.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 18c68d06d5890d977794ce6a3cc1a22d 6040125c886efca89ff76ad296834e26
2.6.31.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7470567730a8a92fa106ed9bf04d48b9 3eaee735c2638e5ca9366c156de2410b
2.6.31.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bf9694c4e8cb35df6a7fa961ebdb2604 45a97e911650f9085fbb4b835c95aed0
2.6.31.11 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 73961039212a73f69759ec5a9571c691 c43d50a49aa9ee59fc7170b7be8ea9bf
2.6.31.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 183033ca01ac9acc29c4c5c3934d910b f307fbbb3b73905ea26e20c48d2f0f54
2.6.31.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4270ee1105fa539454d81df906ebcffb 49892e185efc74eed80ffeee88975717
2.6.31.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 53b37dc7feb156704ba3e6ff41cac8a0 531292d59308acaa989e18bccd782ae7
2.6.32 022 root root d1fef908e3b72c37b925e1a399d1a035 d1fef908e3b72c37b925e1a399d1a035 4b1f6f6fac43a23e783079db589fc7e2 GOOD
2.6.32.1 002 root root 5be63bd57f8672db69198a8ec7a04637 5be63bd57f8672db69198a8ec7a04637 ae1ef1b076bcb75de5452723131d4570 GOOD
2.6.32.2 002 root root cbd1bab8027a01ec42c28278879a7209 cbd1bab8027a01ec42c28278879a7209 edab33d73bf12eb000b51e2248fe2493 GOOD
2.6.32.3 002 root root 8dd90672223a82d8cbfa9bf0ecf6c70b 8dd90672223a82d8cbfa9bf0ecf6c70b cc3056d350e2f960f9d42c954f8f63de GOOD
2.6.32.4 002 root root 2cf5b76b3aa71790215b45afcfa8906e 2cf5b76b3aa71790215b45afcfa8906e 2d30cf9ba08d4c04754a3457e275cb83 GOOD
2.6.32.5 002 root root cc137ff7c3f9cd033bab9ddadfa09b9b cc137ff7c3f9cd033bab9ddadfa09b9b e2341d4f225959358e950833cf0758cc GOOD
2.6.32.6 002 root root d1561434aa81622f6b17b72c8e00c226 d1561434aa81622f6b17b72c8e00c226 11ddb00d7569c6b8747c6c309e8575e0 GOOD
2.6.32.7 002 root root c0fcd24b3b3783afefda8f77b0c95a03 c0fcd24b3b3783afefda8f77b0c95a03 ceff62c9522950a6261120424a3ade1e GOOD
2.6.32.8 002 root root 2e09e2ecd521b5fb43cc577e88e98356 2e09e2ecd521b5fb43cc577e88e98356 813a1d2c3709756d6b234162fd1d89c4 GOOD
2.6.32.9 002 root root 9e1ddce5bf49fbf740fe4967990b3f83 9e1ddce5bf49fbf740fe4967990b3f83 b78dfc2f66af6c964a147f02abd5d927 GOOD
2.6.32.10 002 root root 32aa41fbc18fbe1cf1e8535e677c13a4 32aa41fbc18fbe1cf1e8535e677c13a4 5c1140756b29e34fd7bc284a6abaff35 GOOD
2.6.32.11 002 root root 212f747ca5999b395bcc03799399b8ad 212f747ca5999b395bcc03799399b8ad fddf009351f27fdef561d342ae7e7593 GOOD
2.6.32.12 002 root root b73836b409909ba691e442a851221bab b73836b409909ba691e442a851221bab cfb8514dc683ac7c875d64d31908e3ab GOOD
2.6.32.13 002 root root 1f72687582dd1bf5aa7d9a1b01ac11f5 1f72687582dd1bf5aa7d9a1b01ac11f5 ba0d81958297e448b9794b9c7d8e6853 GOOD
2.6.32.14 002 root root 8af1c02cefc69f902008b6d16e2a5f19 8af1c02cefc69f902008b6d16e2a5f19 2b56e9ffe03bfb6b3913bec21f58b5c1 GOOD
2.6.32.15 002 root root c86b467e8649d5b782e5c85d7bada2c3 c86b467e8649d5b782e5c85d7bada2c3 4c0c73dc4bac0e83981363b7da3f2124 GOOD
2.6.32.16 002 root root 34f9d86da519c3ac868bb6b9c0edf5fd 34f9d86da519c3ac868bb6b9c0edf5fd 8b42d77e1dbf1d4bf7f887643b046426 GOOD
2.6.32.17 002 root root 41fa851916eb3e208eb2d07d9a2edc20 41fa851916eb3e208eb2d07d9a2edc20 af941edba8b0ce5e026e4af9c64ea589 GOOD
2.6.32.18 002 root root e93ea8c463c761b6733ca9550de9d28d e93ea8c463c761b6733ca9550de9d28d 6b4e6f1a012f9bc6de10ddca007d4f5f GOOD
2.6.32.19 002 root root baa03d63e6eb52c870ef5f4dee6bff81 baa03d63e6eb52c870ef5f4dee6bff81 4c07d9ea18c6eb98f0be7f1b2181e155 GOOD
2.6.32.20 002 root root 9b4b3ccbdb161284db7c50d8fa7a9cc4 9b4b3ccbdb161284db7c50d8fa7a9cc4 fb5dbf788cd4669a481cc8913e40f22f GOOD
2.6.32.21 002 root root 4e2d3f2ca147c1d18a0c042bb39e8296 4e2d3f2ca147c1d18a0c042bb39e8296 fbc722a582675ab1039d6f89d60682f2 GOOD
2.6.32.22 002 root root c1bbd1b7be8f5bc5b8ec845ba4cfa6d6 c1bbd1b7be8f5bc5b8ec845ba4cfa6d6 6e9eea6ce8ad06b3d16d872dc192f111 GOOD
2.6.32.23 002 root root 7706a8fa891540f5eaaf0b504505473d 7706a8fa891540f5eaaf0b504505473d e5a0643a9ff87cf4c361d21c7baadf75 GOOD
2.6.32.24 002 root root e19d2bef8b40fe3870bb0b8e9bfa2f4b e19d2bef8b40fe3870bb0b8e9bfa2f4b e43f2b6c1f95e1963f005c422f9bb7a6 GOOD
2.6.32.25 002 root root 1e8ea8d88db9ea220746c317c891c6d7 1e8ea8d88db9ea220746c317c891c6d7 f4c9139704e64eb87228d3dda8df1852 GOOD
2.6.32.26 002 root root 21db42cb4175753d6b702138b2d16035 21db42cb4175753d6b702138b2d16035 b301eade70974269918484c83469795a GOOD
2.6.32.27 002 root root f3b4b1aefc240a75b84ce8c83c1d8203 f3b4b1aefc240a75b84ce8c83c1d8203 4c7b2c1f39a23027dcd1d9ae53e98805 GOOD
2.6.32.28 002 root root c63f9b5a3344f866620f6ae10be15881 c63f9b5a3344f866620f6ae10be15881 acc40b3d114c67fc28857b93fe416c4e GOOD
2.6.32.29 002 root root a6546c1fad45fa336885860d31f89b9e a6546c1fad45fa336885860d31f89b9e ed37db5e3c2865f17796a003aa5d6c70 GOOD
2.6.32.30 002 root root 8b3e0d9612b61cdbf4a9a01566010fa4 8b3e0d9612b61cdbf4a9a01566010fa4 6c43c3c5144f4b4cac0073b052f90b64 GOOD
2.6.32.31 002 root root 5dcf526758804fa382f231073a442ebe 5dcf526758804fa382f231073a442ebe a1202b74ff6db879834b45d4f792e404 GOOD
2.6.32.32 002 root root a3fd490344081ddc863c85e066c26de4 a3fd490344081ddc863c85e066c26de4 b4a0ef12f0c495d4559a0e2199c9f34b GOOD
2.6.32.33 002 root root a22b0dd689764e1aa2abcbc4f3f38899 a22b0dd689764e1aa2abcbc4f3f38899 7341b2f5672f19435434147678be1664 GOOD
2.6.32.34 002 root root 7c596527748f917b0df22321b83c9eb9 7c596527748f917b0df22321b83c9eb9 4e8a70aa35a18fda9e6ff034e15f9a7e GOOD
2.6.32.35 002 root root 31b9c268a72f183b37a609ce1688ed33 31b9c268a72f183b37a609ce1688ed33 19ae9d746a70788bbfe741c1dbc02329 GOOD
2.6.32.36 002 root root 21d809b12592e91d100f40ee9c415e94 21d809b12592e91d100f40ee9c415e94 3020bf5a681f1b9b17cacb5a5dd54270 GOOD
2.6.32.37 002 root root 88572d1d95f9417a93db60a954f3ce9c 88572d1d95f9417a93db60a954f3ce9c 90414a762722e5ff4ed1c0dfe64b52e9 GOOD
2.6.32.38 002 root root 75e4d93ea9c57c28acd169902c70ffe7 75e4d93ea9c57c28acd169902c70ffe7 9a6e34ae9209568e090a64eb01b25078 GOOD
2.6.32.39 002 root root 6d266224d3ff0d136b336228fe108f3a 6d266224d3ff0d136b336228fe108f3a f89848dbd474e25f2b7dedd13c42a401 GOOD
2.6.32.40 002 root root 27cd2ab5f45c83effbca8f894b9bf9a4 27cd2ab5f45c83effbca8f894b9bf9a4 5423e3dca8f18bdaf278f78df215776c GOOD
2.6.32.41 002 root root 3da56d911ae16e1d9d04d27e97140094 3da56d911ae16e1d9d04d27e97140094 39efe42435365ef3a5f0e43bcab8a519 GOOD
2.6.32.42 002 root root 74189193fa0b44a74bfe31de2934396f 74189193fa0b44a74bfe31de2934396f 406b9bb2bde4e54ab210cd7915b627af GOOD
2.6.32.43 002 root root 702e1151878c159021bfed717483d078 702e1151878c159021bfed717483d078 9748e4847f9208f0a8bb9c332e1bc75f GOOD
2.6.32.44 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 29c4da271ccf54602641b99e744cf03b 8cd314a3449280be8537b3aaf14fb6db
2.6.32.45 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2cc2aab8a394e0fe20fca3194718b857 d41f1c7e704cc95fdfc3374367b6fd64
2.6.32.46 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c7847bdc87eb7781c7bcacae5c05c91b 73400c79feb280690c74dd0d9f4ffd6c
2.6.33 022 root root 7fb6c834df94d78ad1dc118ba98bab21 7fb6c834df94d78ad1dc118ba98bab21 47512dfa97ba20245907feca2c507006 GOOD
2.6.33.1 002 root root c604a96b1006c24da58237b9e55195a9 c604a96b1006c24da58237b9e55195a9 7abd10bff798a6171127e69efcf36ee7 GOOD
2.6.33.2 002 root root 6453571f38b4dfaa602f7585a7616c48 6453571f38b4dfaa602f7585a7616c48 f2589ee097d2c69b573babcfd2efe67f GOOD
2.6.33.3 002 root root a940c369b6d48fd3aea62d86d3a3b324 a940c369b6d48fd3aea62d86d3a3b324 a1809b6054650d0fe89152c0459d644c GOOD
2.6.33.4 002 root root a21a8802c2f3a304d79a2b0a6c7d9366 a21a8802c2f3a304d79a2b0a6c7d9366 3f11fe8a42a117ea80dc26bef5174805 GOOD
2.6.33.5 002 root root 614d843285a93253eec2431124c5b090 614d843285a93253eec2431124c5b090 bcad38544b4ab5d4abd766112afc3575 GOOD
2.6.33.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c0c49ff442a9a38bf19b54981c396477 9b9dd78cddf3edaae54ce9041b4d0fb5
2.6.33.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f954231ecad72c06ef7564d46406e44f 3e3cb86995b3c31ecd01b63c1f444886
2.6.33.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 495e5af33b256ff056accf8650986be3 9fe0191d3d5edf9c3fbd4fa9c39a2509
2.6.33.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx faab2b03eff6543c8bf63101309b61b4 2cfee0265daeb53706b7e981814af109
2.6.33.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d0466173fe28142b1079041d35e3d326 21aaccd06eceeb17c017124d915a62c0
2.6.33.11 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bd13cd19cf5ad42a027db60a557ac27b f02801368a879fd6edd8398dae6db526
2.6.33.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cfb4eeb135b2f872d782b51511c039a5 6ea18c9bf4fd909272d9a60ebb1a2ddc
2.6.33.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f577df3c53a265e4a76aeecbd563d332 afde0d498a65c698288422c412e32735
2.6.33.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7805feff0bf8a657d16c5881459f1add 753664a8b45f032f33ef5df7366ba0f1
2.6.33.15 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a807da8ad93204739e739ddcd06afdd4 dd8dd0cbc87a255cdcb69f2d28950de5
2.6.33.16 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7c7d462611cd35e979e3ff2408765bf4 78544082ee6f62171ec6f8e860cfdfe7
2.6.33.17 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9a3f51532f5f753de84145b1bc8dde2f a9950bf9ff5cc84373be7de9bcf21727
2.6.33.18 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5d5666fc2b7b070de62dc9b581ee2c14 9ec37439f478ceff34a2b13cc4cec732
2.6.33.19 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4f7c313f0ec36aa080bea2a29d267978 42bc20e406ee4e3a9292a9969f58b21f
2.6.34 022 root root b36063fb6a50e736dc65f1798b4ec12f b36063fb6a50e736dc65f1798b4ec12f 47ed5ccd99d04352253e43d4bc84ea6a GOOD
2.6.34.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b5ab09577bac71665b0a6afc01aa8991 198c29eff8256c851e2b8e9a1369339c
2.6.34.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a51d818279e0402e0f9810f1a81896a4 971c406b402d5c0a46800ce3cf644d1e
2.6.34.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4171780e929adb9bcf845894d4b34772 eac833497feaa8c5896e3fb79dcd8ad8
2.6.34.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 13f3eb829305c9662a7c61808cd78f5e 8017efe8c7fd53ff4824b91e8740049e
2.6.34.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b52ed8d879f462f80b4171874e345ce2 b27b341b54e4378e7ee461a308c7402a
2.6.34.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6ff1290538fc568f5c5dec8be92e7304 3884b783e8a596944afd912cc08a4073
2.6.34.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 20d960afa5c81924595bb631aeb25bfe cd6590845d33987e2b67c36e93254082
2.6.34.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9fdc14cbd5272d7951536567ea4d9f28 822311a54b7008642a2f9d76063f63ba
2.6.34.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f81345937f54527cdf05e6e288ca350e 3a5ad3845fb5224924b2d4bd55b0b072
2.6.34.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a82c7a3b88e347b158251688020d5206 f60bd1faf6ccec530eb0b9a1ab55af7f
2.6.35 022 root root 76e96f2df4eeea351787c65b3b264986 76e96f2df4eeea351787c65b3b264986 62001687bd94d1c0dd9a3654c64257d6 GOOD
2.6.35.1 002 root root 208ecf7446037da8929cd89d00201eb6 208ecf7446037da8929cd89d00201eb6 a88f1bcb6d331155cc0cdba9a3cdb508 GOOD
2.6.35.2 002 root root f05f0e9210ed73e1f2471d3c5053a959 f05f0e9210ed73e1f2471d3c5053a959 1f2da16491fe2c3f68a48170749c1731 GOOD
2.6.35.3 002 root root 1cbcb42ebbfd2644ec671ec76c30ade7 1cbcb42ebbfd2644ec671ec76c30ade7 887800197a74a160de27f53cd3a75c79 GOOD
2.6.35.4 002 root root 19a1f86ee7412f80f7ce169a5e126923 19a1f86ee7412f80f7ce169a5e126923 6a2d7e0fa99bea0a3c209c98a3745466 GOOD
2.6.35.5 002 root root 2e5f5a226293a3c56dad081887ff809c 2e5f5a226293a3c56dad081887ff809c c86fcedd98ab0d64fe981575bb06a5c8 GOOD
2.6.35.6 002 root root 2f7443cf4efbe36239bcf14488c5a883 2f7443cf4efbe36239bcf14488c5a883 55b944af9b96651cf8a34e4a7fa38a1b GOOD
2.6.35.7 002 root root bb61b92a0570d10eec4dea37aa84c605 bb61b92a0570d10eec4dea37aa84c605 e09a37dcfdbf256ef20039d0d8fb8058 GOOD
2.6.35.8 002 root root 7038815cdb8de9591da6509ae6925714 7038815cdb8de9591da6509ae6925714 51981683457e3cf19b137a5a0df8d0bb GOOD
2.6.35.9 002 root root 83d50d1b4c46dadab70da7a2172d0819 83d50d1b4c46dadab70da7a2172d0819 85967dc97fb1d5ee50eb53375a652d93 GOOD
2.6.35.10 002 root root 122a6b0854a9b461dd1271afa6c29826 122a6b0854a9b461dd1271afa6c29826 5f8d0539af9b94a1b5ffef1f3358f73a GOOD
2.6.35.11 002 root root ff345053ea0724127f36a7305afa4340 ff345053ea0724127f36a7305afa4340 f3b6db4ca6f1b9856a20f2c160d527e0 GOOD
2.6.35.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6685f3b35b5df4f19290b70c787c4650 7eff266164b794ddaf07d16a5d650259
2.6.35.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3cbd9006a7cde4efc2ef669aced7e5fc 2c02fb9f091673aba3e3203ca8a55168
2.6.35.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fc558717fc5ce042f83f6444285c33c6 dfe2630473a7edea339a736ffac67eec
2.6.36 022 root root 2f4d3b5d66aa1c1465e0c05e3c5f36ac 2f4d3b5d66aa1c1465e0c05e3c5f36ac 9083f8da705b0102bcb8999079437132 GOOD
2.6.36.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 44944e1bf4bbe6be6c9b19caabd2e46a ef410ffece297e8b827fec99cb32b32f
2.6.36.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8b6557c4f0cef60b1c0cfd389ac76c81 79383b9cf01cd4b9255b8b9e3a80b0c5
2.6.36.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ac4a519bd303d1552bdf2ef28cea9400 da2224c44d3316fea2316a0ff368b4f1
2.6.36.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eb84076b4f2ffbe6ec397db09c4b76c0 77b981f8319d238856e6e98b3aac0e50
2.6.37 022 root root 943a4f25288d86b1dbf7808eb539bd42 943a4f25288d86b1dbf7808eb539bd42 c877f8429254e4a4981028b90ea9bb10 GOOD
2.6.37.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a358b14b41133571d8d006c1799c748c 588bef60117c34162b1835f9b0ec5251
2.6.37.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 42865250767ded55861ae0cc569f4cdf 136adc84115d9529a11c875cc861cf8d
2.6.37.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4cefa352f70a1f5b61f91a7ffcfe4f5b c498fd2c9451849117c1ed29a31466c6
2.6.37.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1faea970049f982abd1f735c0eaf5200 639108993d53de32ae3fffb5eb2820ed
2.6.37.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 918d912d411ecafe07c4c536a192a860 9c01abb4f975f9cf3b5e3dffb62292ae
2.6.37.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8c5acdd2de588e03cf788f51ba49fd52 77016b346480466d649ec9d719d8df0a
2.6.38 022 root root 0e705fd53756f7bddcf6e4bb3f18458b 0e705fd53756f7bddcf6e4bb3f18458b cf0b587742611328f095da4b329e9fc7 GOOD
2.6.38.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7e61835baf0e180582e7899a53333d36 e7ef42ccbcb0fd716ef25ba1970ff64e
2.6.38.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 28b115c1e5ef3311d83449ca55eb1e93 7b45f4d238bf736f8dd4bac293d40d56
2.6.38.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7241f0ed5fdb946958ae07839dc37fc4 6d2ace2e134dbed592dee16320bd41b2
2.6.38.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7e79df0e18344fb38a5222df07124ba2 da2cef8f5c99a664e8b3b86674c49c05
2.6.38.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c334701518dee7a785f24d10b684287e d59b33f52c32e891690a5ec0934b9c88
2.6.38.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f78b06daf92715dba4f5524eda2db4c2 9ba1b51b427c917f9dde69a6b1b02bd0
2.6.38.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d8ae75de84c9c8a80b3ae3628550dbe1 f1ae7efecc2742a33141fa64b9370135
2.6.38.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9f98099e7e89e6eacfefcde48c72c459 f779b3991fcf0e4573a5d5167a60a26b
2.6.39 022 root root 833d224ee42ddc1e7c2d256368b5d7b3 833d224ee42ddc1e7c2d256368b5d7b3 d3b7d50f09c2b396edd6dd1fe8561a62 GOOD
2.6.39.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3ec312d569811554efce499b8f5f655d 018a6ed132dd44531d11c5d56f4b528c
2.6.39.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6d5d0821f9febfcba8ce652872240b80 e5010f5da6ba96f1b31f658060439348
2.6.39.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1b9fdd3b3ce19eec99e5c22d54c466f9 650de652a1f78c60e140f1b3be47f5e9
2.6.39.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 829d4bd2e2d2f91b8ae36f52b6f38836 1b834c566316219312e46770021e9f4a

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Sat, Oct 01, 2011 at 03:36:58PM -0700, Randy Dunlap wrote:
> 
> Who needs these privacy keys?  Is it just (git) users of kernel.org?
> 
> so people who send patches via email do not need to do this process?
> or are we headed into sign-all-patches territory soonish?

There is going to be discussion about security procedures at the
kernel summit; to date we've been focused on the short-term
requirements to get git.kernel.org back up so that the next merge
window can open up, hopefully without getting instantly compromised
again.  That's going to require the help of everyone that we trust,
especially from folks who are maintaining git repositories.

I personally don't think we're headed into sign-all-patches, since
patches still need to be reviewed, and at some level, as long as the
patch is reviewed to be Good Stuff, that's actually the most important
thing.

That being said, if you have a GPG key, and you can participate in a
key signing exercise so that you are part of the web of trust, that
also means that you have a much better ability to trust that git trees
that you pull down to your system that have signed tags are in fact
legitimate (at least up to a signed tag).

So there are good reasons why developers who primarily participate by
e-mailing patches might want to start using GPG.

						- Ted

Re: kernel.org status: hints on how to check your machine for intrusion

[H. Peter Anvin]

On 10/01/2011 03:43 PM, Willy Tarreau wrote:
> 
>   <version> <umask> <user> <group> <tag md5> <tar md5> <tar.gz md5> <status>
> 
> Since I can attest that I exclusively extracted the tarballs from the
> tar.gz and dumped their md5 at the same time, I'm pretty sure that the
> tar.gz's md5 is OK if the tar's md5 is OK. This will help speed up sig
> checks on mirrors.
> 

By the way, it's usually better to use sha256 or something else more
modern than MD5.

> All the times I got a different MD5 between the tarball and the git
> tag was because of a different user name in the tarball. It seems
> that old git versions used to use "git/git" instead of "root/root"
> now.

Yes, that change was introduced in git-1.5.0-rc1.

> This is hardcoded so it's not easy to change it, and I suspect
> that the tar format might have changed a bit, so if we want to check
> those MD5s, either we check on old mirrors that are 100% safe, or we
> have to reinstall an old version of git.

... or extract the tarball and diff the contents versus the git tree.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/01/2011 06:04 PM, Rafael J. Wysocki wrote:
> 
> OK, I'm taking this as "5 years is fine by us". :-)
> 
> And the recommended procedure for rotating keys seems to be (1) generate
> a new key and (2) make as many people as you can sign it before the old
> one expires, right?
> 

(3) revoke the old key with a status code of "no longer in use", or just
let it expire.

>> Some people have decided to opt for an unlimited key, but that
>> *requires* that you have a way to revoke the old key, which is why we
>> are considering a key revocation escrow service.
> 
> That service will be necessary anyway in case some keys are lost or
> compromised.
> 
> I wonder what the procedure of restoring kernel.org access in case one
> has lost keys is supposed to be?

Get a new key and get it re-signed.  We can work out specific details at KS.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Sunday, October 02, 2011, H. Peter Anvin wrote:
> On 10/01/2011 02:33 PM, Rafael J. Wysocki wrote:
> > 
> > OK, how long should the new key be valid?
> > 
> 
> That is a good question.  At the very least you want it to be valid for
> long enough that you will be able to get enough signatures on a new key
> *before* your old key expires.  As such I would recommend 3-5 years
> depending on how much you trust yourself to keep the key secure.

OK, I'm taking this as "5 years is fine by us". :-)

And the recommended procedure for rotating keys seems to be (1) generate
a new key and (2) make as many people as you can sign it before the old
one expires, right?

> Some people have decided to opt for an unlimited key, but that
> *requires* that you have a way to revoke the old key, which is why we
> are considering a key revocation escrow service.

That service will be necessary anyway in case some keys are lost or
compromised.

I wonder what the procedure of restoring kernel.org access in case one
has lost keys is supposed to be?

Rafael

Re: kernel.org status: hints on how to check your machine for intrusion

[tmhikaru]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

	Any way we could get something like this verification done for the
3.0.x stable kernels?  I'm currently stuck without any way known to me to
verify that any of the patches I downloaded from kernel.org before it went
down are actually correct.

	Tim McGrath

[-- Attachment #2: Type: application/pgp-signature, Size: 482 bytes --]

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Sat, Oct 01, 2011 at 09:58:38PM -0400, tmhikaru@gmail.com wrote:
> 	Any way we could get something like this verification done for the
> 3.0.x stable kernels?  I'm currently stuck without any way known to me to
> verify that any of the patches I downloaded from kernel.org before it went
> down are actually correct.

I already sent a signed copy of the 3.0.4 patch that applies on top of
the 3.0 kernel to the linux-kernel mailing list a few days ago.

That should be fine for what you need right now, right?

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[Andy]

On Sat, Oct 01, 2011 at 07:26:43PM -0700, Greg KH wrote:
> On Sat, Oct 01, 2011 at 09:58:38PM -0400, tmhikaru@gmail.com wrote:
> > 	Any way we could get something like this verification done for the
> > 3.0.x stable kernels?  I'm currently stuck without any way known to me to
> > verify that any of the patches I downloaded from kernel.org before it went
> > down are actually correct.
> 
> I already sent a signed copy of the 3.0.4 patch that applies on top of
> the 3.0 kernel to the linux-kernel mailing list a few days ago.
> 
> That should be fine for what you need right now, right?
> 
> greg k-h

Greg:

Would it be possible for you to build on the great work already done by
Willy and provide the signature's he missed (they cluster around the more
recent branches which happen to be the tarballs most likely to have been 
downloaded during the intrusion window).

Maybe it makes sense to generate sha-256 fingerprints, as H. Peter says,
rather than the less collision-resistant md5.

Very few people probably have as complete a local git repo as you do.

~ Andy

Re: kernel.org status: hints on how to check your machine for intrusion

[tmhikaru]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Sat, Oct 01, 2011 at 07:26:43PM -0700, Greg KH wrote:
> On Sat, Oct 01, 2011 at 09:58:38PM -0400, tmhikaru@gmail.com wrote:
> > 	Any way we could get something like this verification done for the
> > 3.0.x stable kernels?  I'm currently stuck without any way known to me to
> > verify that any of the patches I downloaded from kernel.org before it went
> > down are actually correct.
> 
> I already sent a signed copy of the 3.0.4 patch that applies on top of
> the 3.0 kernel to the linux-kernel mailing list a few days ago.
> 
> That should be fine for what you need right now, right?
> 
> greg k-h

	I completely missed that message. I can use that, thank you very
much for pointing it out.

Tim McGrath


[-- Attachment #2: Type: application/pgp-signature, Size: 482 bytes --]

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Sat, Oct 01, 2011 at 10:30:58PM -0500, Andy wrote:
> On Sat, Oct 01, 2011 at 07:26:43PM -0700, Greg KH wrote:
> > On Sat, Oct 01, 2011 at 09:58:38PM -0400, tmhikaru@gmail.com wrote:
> > > 	Any way we could get something like this verification done for the
> > > 3.0.x stable kernels?  I'm currently stuck without any way known to me to
> > > verify that any of the patches I downloaded from kernel.org before it went
> > > down are actually correct.
> > 
> > I already sent a signed copy of the 3.0.4 patch that applies on top of
> > the 3.0 kernel to the linux-kernel mailing list a few days ago.
> > 
> > That should be fine for what you need right now, right?
> > 
> > greg k-h
> 
> Greg:
> 
> Would it be possible for you to build on the great work already done by
> Willy and provide the signature's he missed (they cluster around the more
> recent branches which happen to be the tarballs most likely to have been 
> downloaded during the intrusion window).

I've did this a while ago when we were working on verifying the
tarballs, here's what I got, one column is with the umask unset, and the
other set to 022, both of them being the sha256sum output.

If this isn't sufficient, just give me a script I can run and I'll be
glad to provide the numbers.

-------------------------

linux-2.6.32.1.tar: 363cfe86c06fd1be2c3214fa35526ae849609194196b0aa0cd44fbded888e7e9  -  30e3b4d7eea088515ee9fadaad0d8b68f5a9f83c3a8c39789ca000b267a68569  -
linux-2.6.32.2.tar: 4552b3e7b36c34a5cd070b96ce479c258c7ab55437b01491741c8acdfaa08fff  -  daf0fa72694eb27f896d98d38ae7da56d6d36f3e75f3a338403da1535e98a965  -
linux-2.6.32.3.tar: 5f7f2123a31676c38d296cc154903564ced9e3873e07d149f9f20714ff4eb398  -  0b2fe78f3b2b418f322e169c72e5442f59c9a1135133d9d6a320a00f3551a2ba  -
linux-2.6.32.4.tar: 81350026d83acf4811efe03a78b613a6cbd6b61ba219a0eeb67d23b4c66b2a99  -  d828ab88d5e612c33e4bf9a5ca86da41d5e33752b046c7857998003da5da2ab3  -
linux-2.6.32.5.tar: fb11215e116122211c5002d207804491bdf1615d1da43701a51c862b5a53ec96  -  54d9906db8cba12000bf30b8e86c299b21441aed721c09f7fb89ae429a6f3763  -
linux-2.6.32.6.tar: bf9dd7d0feedc550190d252828116a7c9959cc95975718751fc7eed1127969be  -  57991e077861dfdc86b33b022808e8de05255ddfaddf44f8a18ac76e036b5846  -
linux-2.6.32.7.tar: 06dc33b3a25e3d06976bdd2f30d83db5ef9ff4945fe663b7dd5b9b45d66f3a44  -  e32c018ef3f6c44936da9995d069c422c192218c08ccf2b98c3eccab59d2d72b  -
linux-2.6.32.8.tar: 6902efc58533ad97ca3379b938cd0a4df45c21d57867de431089c55b6c6c7b3b  -  14e7c3fc62aaec071166812ea5cb0dff4a0f14b6ef14321e730d468d8a408797  -
linux-2.6.32.9.tar: 6ec8bf7ec098609507a4d67a193c1c764219b27ab2c48b5f5666057be9b2a3ff  -  5c22c43efb7809dd11be0fcb3192dd6c347c011242dd0b8622f3ace99d22f31e  -
linux-2.6.32.10.tar: 5b954cc23a07f1f03d8fcdb57d4461bc1347aff95b7d3b91dbbe8cc5169e5155  -  cfdcc74f0dc81e08a50d6f613908e70ed38cc57a8603c372104c311aca112b1b  -
linux-2.6.32.11.tar: ca10be946879e7c30b2fb519057b08eb05a0939fe4228ba3f7ad1378b9060c97  -  5b05c19e9a322cfddf2f358510bc13665b81157698b11fe78d5dc864c6b4bb4c  -
linux-2.6.32.12.tar: ab44569ed54f0b4e7ca9ebec772a6d6d800db1dfec96fef0b162a893f0ec1fe2  -  bb516126331e24a31d69677ae7f657e54214f635becc831ed0140f719829c847  -
linux-2.6.32.13.tar: 03cbca68ea1bd792f9482e1789a81cbd0be6f3a06fb253365d0fbbbb29106a75  -  102ebb06e2d5b961d0e50cb385b6653c54cd6895eff83291e445d71e38ea00f1  -
linux-2.6.32.14.tar: dd4eb022438ff1358663da4a75d9e62bd95ebc4b6e8a163f7eb776cf6d28bb93  -  603eca5531d1b39b4d02c03781ac98b3fbbef548eb449eff06c97cd85b755d53  -
linux-2.6.32.15.tar: 536d002526a096af3e93d785635fd6aaacb8e60e6c12688a637edd6ed8d67ce6  -  f274e28a6e42e1a1dc03c4cf9273317a7efb172dfdabab8ac656aa86b4ea2fd4  -
linux-2.6.32.16.tar: 3a0188eedf990f083c38f30cda7db0afcb417ed1f530a3ce43ea55587455d8e2  -  bfc6f6848a2315c4c91813ae7278c5ce60a90e186b65ffff579b8225e9342341  -
linux-2.6.32.17.tar: 94b6aa48a5e9293bd667d54f301caf43565412640eeb9a847b5a0773673b012e  -  3e30bfb8623a43cda2411a6aa67cffed7e1c8f1155145371342d360fa696937f  -
linux-2.6.32.18.tar: 1c8e7bbaf9cd4f5696162f5e2e8f2212349ba944f026e79405c9c3c0e0ccfa18  -  dabc805c2cb68d0b1fe44b50b2967d438e5495c36a9a7a5a5c1688625cf4e052  -
linux-2.6.32.19.tar: 7d8532a6ad57e4d60f9481599c35905d96f33c8024edb23be89b7486ae10e7da  -  ba4fa3bf89c521179bd0017631fb5413ac9f5555d16b271e9e6af1a70c756ab2  -
linux-2.6.32.20.tar: 71013dd7a9932204df125bfde8aec4d71704a4287e3539aa547feb1ef9d19c34  -  6945b677a405935e1dcf220ce75b00ee421f78d0e3546f3cc784f7e73f4736f8  -
linux-2.6.32.21.tar: b67daa633e8f4b478ddd5b81c5aa081174799343f8993d29ad7ec7440a1568df  -  b2f5852687b57464544ba0a0c4170191a83f84a5083b5dbbaa7d1abbf43b5a18  -
linux-2.6.32.22.tar: c0271a0430303b841c8b9ee7225f27b76792f8f5b6722306d4bec0786d6ee40d  -  aa10794d725868a124492e452fb6e9279f7f81889d94c5bc7f2e07bef7e23218  -
linux-2.6.32.23.tar: 573fe525797829aa6bdb4cfaf05635c1f12f6695c9e82dc3e37a2644bc4d6335  -  44d23529dadd7fd0ba3788f75a3bb40182d988bb6a72d9c2d2c7a15738a31e2d  -
linux-2.6.32.24.tar: 3b99e8467c21aa81baad46f918cea7cadf50cab1bf7aeba69c33b374d0df0780  -  99888e270edd3aa07725d80acd8d59dfa45efe354cc505fbd7441e66a1c227c2  -
linux-2.6.32.25.tar: 81ee9b626dc19ace82d9585e33d41827db4dc02ad34cb376f963979a29ce50fe  -  aa1f7beb97a9b8dff44ec129b6a144d0bdb358d35982c5f05341c72c8dfe651e  -
linux-2.6.32.26.tar: 6e8d727663fb1e1cc166aa732d4c62e55fe355676a4422d17e5870d4f075aee5  -  d52fbf8d9db5f11907f79f6284b358f19c85720a51892a3dc404381ce6969072  -
linux-2.6.32.27.tar: b48cf5e0689863d71be347d95e39025b2aff25464bebe67a384373df609858c1  -  ea9e887065cc93ce9a9ad5d23603df15f8e2fc37119a279d13fd97f39b91b698  -
linux-2.6.32.28.tar: 5bb8bf9893879ce1e74342382116fc2b143fd3a6a0d7177d6f7e75c040c5f8cb  -  7c656e1230ca1753528650cdb654f0cf0f2479b0225618dcdfa6b4d1fbd19a41  -
linux-2.6.32.29.tar: d221f1d3be17cd3c73d990d84daf7f313495114c5428c4a8a1cb571b6e669caf  -  648270b1afa648b0fc3cd6358ea08fbcfd8ab7d3cbd217ae9144531bc13de320  -
linux-2.6.32.30.tar: 7468b8e911b2d4cc6b37316263ad1de83d876f2129c8e35e48ee590a0f8f3468  -  cfb108fc0e3284091ef3c4474a587e1bbb974995d1037f08130a483c2dd30913  -
linux-2.6.32.31.tar: 81391614f8de09a1a0593c367df2488a451625cb70eddcf112fbac4488a18ec5  -  221aa78feb61218c75881e5e6e7d925edafd5d89a6a4be60bf398968195b817e  -
linux-2.6.32.32.tar: b3b587ffa03d6789ea9b29c53ac617266daf9eaff7ae385f98cc71c2ee4793ca  -  be893ac71188e18051b190be907ca70efe09023f3ffdc5365b6e9d595b3cffe4  -
linux-2.6.32.33.tar: 046422f7141d6d9592bcd3fc4d6fa19c2c3fc025b538e0aac6cfb7cab536cc11  -  bf4495488220a9290cc833d4c1f98d8d0227238e538d377ae8133f3a69c194ee  -
linux-2.6.32.34.tar: 0fb3272394da71f74f9c419eedf5e64eb78a2c6c40715b57b4919e203606c23d  -  16c121c04d45c8b757257217589560de89fc9b6ca249034aedcf5a3cb92fc24a  -
linux-2.6.32.35.tar: f2fac849892d21d12f18b0b515560036d008052da5684bc9384f34c68928405c  -  02ee3ea078a33e78908c42cb22130446181c6181e44f7427d50402d18da225f9  -
linux-2.6.32.36.tar: 027d88ea30b0968fefed15ebb3c6a13df3b07c68afa81cfaecfd679bb23aa6c6  -  4beea78871ee36fb05d7aeca3a4255614572ac5676ac5c87be0ea77c0fb6afe9  -
linux-2.6.32.37.tar: 8715dfd50df2ae509d44107f547ba6f51d81ed6fe9cecf73638eabc7009938b8  -  22a55bb79bdfa3cb0829d8991fb6556bef949b6be1bf33bd210f8e172188f71e  -
linux-2.6.32.38.tar: 9aab15ed933ef939b2e0b5e293a41924734795188e006e99f35ebd9e1f2fedbf  -  b0ca7601abe7eeb2b0d96f9889d04b482a9e337c85170616adad869f040915a7  -
linux-2.6.32.39.tar: abaf34298b0da984e945efe38645ff02813f034ba47dc5a76225fbec0de4e2fe  -  a52c3ac27e9b1ff17203176b2690283d52a7b59f838baff797f825254e909b5d  -
linux-2.6.32.40.tar: 3cd0a787cf72f7a618c0b6689ed0caa929ca846b41d37403f6692e1d51fa614a  -  f5f5ce634100e010dafc97eba2da5b870e7f979d2173d18f59d6d97df257d74e  -
linux-2.6.32.41.tar: 4df4bc53e797e3e78abd89e3a4f4c27559126118d8b19c07cd66e3be38d4b438  -  55ee6808b75c0b9e100ac22fed651756bc1bddc97da6a4bc6f33c33afaa47002  -
linux-2.6.32.42.tar: 46233691b1bfa885fca0eccf4bbf774d88872e91e76c0e3b2ecd36d0026bed85  -  2f4413cddebaf55b8ae2dc4a4ecc35d77cd4c7aff43e679f7ed49f503676efa4  -
linux-2.6.32.43.tar: 3d31fa98aa1db445d7831e0791c9bedbac66de50769a3f07790c3c9b513a7684  -  116e8e05e3581e0dc665e559755f69a2e8f5b9d128d675836b46a29b0b3dc6bc  -
linux-2.6.32.44.tar: 178979b7bf9db437406f1b272bdd7b8c63f73ca4ad720d0de3619627a069a656  -  4074f11e5e2ddf91e16a462409210aa7abdc6909c73e9a0791bd5b9e6ebbd7f8  -
linux-2.6.32.45.tar: 499954514965eeb2416380f485f677a0fa7db5ec608762cdd731f571b2932343  -  a9204707a0375566e686e6a28da5962ac759d135371009aa99878ad6dc5e46c7  -
linux-2.6.32.46.tar: 29348c49210ffa7f301dba7c667906e9dfd686f786bd6766e04293de695c2ddd  -  ff1eb5a930921e30bb7574f9a3ea204f5f1f9739989d7f8685499d59233da622  -


linux-2.6.33.1.tar: d087bb0fbd04e6e0030a1937aab92d32f5dfbb4b6a86b645d8a0f4192ffe8003  -  f15a1ecd38bf2ef57844fbe7e427ebf04007d1e0fb509e9ee9208e4d1b502383  -
linux-2.6.33.2.tar: ab3c105e7500b339e3bfa7e271189af5ac54656b2cbc1c6b89e151f9a55f6b07  -  804311c5551ea81697f99fe95d345410eed071d149444ad6cb71b6e5a1dbe181  -
linux-2.6.33.3.tar: a0f53e811e496d8e3a93b03dc1e56d9a7166df02a77538bc72463ecc8d298d26  -  edff5b2691bfb4ab4e37141fda68250985999d2883e374a95846547dc0cedcb9  -
linux-2.6.33.4.tar: 98f99c1d6180c6a748b0181468242229a67d0f77287b2b16443316a6c8c1e9e7  -  eb8e0b46cb74899e0cf461b752c6095d38fa039098543004c3b120713b807087  -
linux-2.6.33.5.tar: 03dafa55ccc7d3282fb668176b51cb627711cf33a4dd03b6147bb32e62d520e5  -  9f3f2a4d0066c378f2b610888e0e2efff1a428349f1b968772d915a7ab771a85  -
linux-2.6.33.6.tar: 6f98810547209639e2d672506d67bb63529823692ce47b03808a0ac305079876  -  cdaf41b05d56e471fc98989046725e536fd8202e7b614e87b6b4707fca88327d  -
linux-2.6.33.7.tar: d90bd548c7f7d5f9bf27bc37780402e4e22e1624f3dbb212f8d048914eab7262  -  f6493ca845baacb59ea4edb773d4f8c82b805d80620975d3c01ce17640366c4f  -
linux-2.6.33.8.tar: e30c41b4d94cae57f0cb5c2be16ce19b0ef3ca29503a0d6e07b0e5c931e3c28f  -  25cf5614a37f4f5f000882a23c481aedd2998bc66ff19ed7507bef4b539b9963  -
linux-2.6.33.9.tar: 920311bc4b8036064501e742d6bf6231125e79ec76c8770dda477107637480eb  -  48112ee13a7d8a1993ac2099b8ae32fcdeac3f0feaeeffaaf3f727b5d2063a90  -
linux-2.6.33.10.tar: 36217bc1d6051aa3280c5e8304055b5a1dc3c892af1e0224c5ce92706daacab1  -  c75fc8afcd6b80b32036e08ea87aff15727706f0503c266ecc57878746f3a6d0  -
linux-2.6.33.11.tar: 59c571dc73529c1730bb34f375de33fde14622c214278f7703a792ed37c6bc4a  -  e9f499a4a70e3df63092f530178c0c0a4094b44c60102c2a3f1b72c8be09f223  -
linux-2.6.33.12.tar: 6d01b56ea4901bb3230feea274dad591ad3e78084fb546567507c6c3b7401489  -  dd129d648aa14adabc9c96417fc3badcb5ffed60e8308bbe4b1778669a2d0c6d  -
linux-2.6.33.13.tar: f4aa0430416d7ea7cf0245474e9a5da0df951ddf628ba7fc1fb586e96f112d07  -  a53b76597ec39f0392719d9ea6179b2780e64a58f72e565845995f3f0f735570  -
linux-2.6.33.14.tar: b6971732666150763c2489209d1588b9caa0ac289efb2de13ac762ca9089d640  -  a76c6801418fd33258c737bebde194b3fb270b95696852c95455132aef1b4dfb  -
linux-2.6.33.15.tar: 0894c0ba28bb325d91bced8e1ee76aeb159294510a1815cf2e247fbd14aeffb9  -  8131c0d6e1a086c276a13323a75179dcca9bb463b6be015d77ed8798680a43d4  -
linux-2.6.33.16.tar: d58a53063691301f1463605ecadff9141a4b72f639013f3fa1fd5c60bcfe3c14  -  5e12c009eddf9e75fd55cc9056499c5852c4c00618aaee88b4ea9ee304e1f2a8  -
linux-2.6.33.17.tar: 4538a62eab18ed6862647ba1a2cc965d5a82e93f8f15ac453fab17376e31dccb  -  c49b4730d95e8febb1a060e8b9ac398708169629d671133bfa207824ab9ae91f  -
linux-2.6.33.18.tar: a0e7f36a967b68f3c59dd41501a37598ff471bbcfa904537552943283018a770  -  430880efb73182937344ee8dfad4e82954734644f6779ae0b1c389aa9efb5665  -
linux-2.6.33.19.tar: 8f6f2a9f2be95a7f3741905f67081a542b7cdc5053ed610a36bd6c7f2e5b6573  -  c65e581fccb384fabc08d9fa8915457cc2f32c10b6874ffa1e2726a7e31b03d9  -



linux-3.0.1.tar: 5296531e3dbf7bf55573a2f400403061340eec801ecbaade9793791827bd5b1f  -  62a609a5c66b2e6fcb32204d812ae211554b9a07630c9ec78660f3682d6da529  -
linux-3.0.2.tar: d2c0636033bbfc6722e71b566cdc95265cf10af300ff2c3f8fba9ab7ec63b725  -  595062c115c7369a2659c06189080f8b079a09bdd1bd447ccbde05f1a8f6289e  -
linux-3.0.3.tar: 92769e812e8fc83b226e97d5732d2a0eb96e598f096b4f10085b0352be7492e1  -  e5e75e47cb5ba91d980aab00c85a9f3e9f8faf0c59c4d5f5dd732555a5f88943  -
linux-3.0.4.tar: ca42bbbffb6db60f16a7870bc1f3ddc872596d9ef1bc4794377ed1da101f14f9  -  4d8856b2c0608568450774f4d475aba6581ca693ac92d070a0d376753e75a630  -

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

Hi Peter,

On Sat, Oct 01, 2011 at 05:10:44PM -0700, H. Peter Anvin wrote:
> On 10/01/2011 03:43 PM, Willy Tarreau wrote:
> > 
> >   <version> <umask> <user> <group> <tag md5> <tar md5> <tar.gz md5> <status>
> > 
> > Since I can attest that I exclusively extracted the tarballs from the
> > tar.gz and dumped their md5 at the same time, I'm pretty sure that the
> > tar.gz's md5 is OK if the tar's md5 is OK. This will help speed up sig
> > checks on mirrors.
> > 
> 
> By the way, it's usually better to use sha256 or something else more
> modern than MD5.

I know but I wanted to use something fast enough on this small
machine. sha256sum is 3.5 times slower than md5sum. Also, we're
not necessarily looking for an issue by which someone would have
spent his time trying to make an md5 collision here ; re-signing
a modified tarball with gpg as root would have been a lower hanging
fruit.

That said, once we know the tarballs are fine, it will not be that
hard to rebuild the sha256 of the compressed tarballs and match them
against existing images.

> > All the times I got a different MD5 between the tarball and the git
> > tag was because of a different user name in the tarball. It seems
> > that old git versions used to use "git/git" instead of "root/root"
> > now.
> 
> Yes, that change was introduced in git-1.5.0-rc1.

I noticed your comment on this in another mail, thanks for the details.

> > This is hardcoded so it's not easy to change it, and I suspect
> > that the tar format might have changed a bit, so if we want to check
> > those MD5s, either we check on old mirrors that are 100% safe, or we
> > have to reinstall an old version of git.
> 
> ... or extract the tarball and diff the contents versus the git tree.

Indeed.

Regards,
Willy

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

On Sat, Oct 01, 2011 at 09:39:48PM -0700, Greg KH wrote:
> I've did this a while ago when we were working on verifying the
> tarballs, here's what I got, one column is with the umask unset, and the
> other set to 022, both of them being the sha256sum output.

Thank you very much Greg, that was really helpful.

I re-ran the checks on all those images here. I have updated the
table with a tag "SHA256-COMPARED-OK" instead of the MD5 for the
git tag when I could check that the sha256 of the .tar matched
your tag.

The script ran almsot all the night to check the bz2. I'm posting
here what I have. All the 2.6 kernels between 2.6.0 and 2.6.39.4
have been hashed. The .tar extracted from the .gz and .bz2 always
matched. All tar sums that could be compared to a valid git tag
did match too. I'm attaching the report in the following format :

  version umask user group tagmd5 tarmd5 gzmd5 bz2md5 status

I ran the test on 3.0 with sha256 too and could verify that all of the
tags match the tarballs, and that .gz and .bz2 produce the same tarballs.
I'm appending here the sha256 of all of them :

7f7498f6fe78474b986ee2fd617e4def35041547b2d6f5fd6b347dac592e399c  linux-3.0.tar
64b0228b54ce39b0b2df086109a7b737cde58e3df4f779506ddcaccee90356a0  linux-3.0.tar.bz2
37e8a1b5d1e488cd9a57cb601d2647ea122fd5a7644a6c535d98282925d025e4  linux-3.0.tar.gz
5296531e3dbf7bf55573a2f400403061340eec801ecbaade9793791827bd5b1f  linux-3.0.1.tar
8603c451d6779f55175c2c96a92a40177c89ed4e0217501258214a64c9c4e127  linux-3.0.1.tar.bz2
c786d357d61719bee5da6a37cd01a0061c5a9fa3854334473e68dc0761b56874  linux-3.0.1.tar.gz
d2c0636033bbfc6722e71b566cdc95265cf10af300ff2c3f8fba9ab7ec63b725  linux-3.0.2.tar
0bf66062e2bc23e6fe6fddb329fe06c6994ba5b016c89e2afdf093c059b5c035  linux-3.0.2.tar.bz2
e5a605780183e90bb23784b27ff835215a3ccefaf414bffee375d6bae4bf7048  linux-3.0.2.tar.gz
92769e812e8fc83b226e97d5732d2a0eb96e598f096b4f10085b0352be7492e1  linux-3.0.3.tar
b6a035d724a85f52b6973d11f43a3d215a3226dafc74ea89b8479d4cd4896788  linux-3.0.3.tar.bz2
298b66f3a3d71aa0b6a9ebe73f67b22974e1de51c4093abfd419f462e3c8246f  linux-3.0.3.tar.gz
ca42bbbffb6db60f16a7870bc1f3ddc872596d9ef1bc4794377ed1da101f14f9  linux-3.0.4.tar
13d689714502ed0e4d6224dd322be8b1b4fe39aa3471fd892bb09c181b93d7ef  linux-3.0.4.tar.bz2
0de107e7d73709d772e87dc08ef846b4f7616525a22890430cdb77929cd999f1  linux-3.0.4.tar.gz

That way it's not needed to decompress tarballs anymore to check them,
it's enough to check their sigs using "sha256sum -c".

At this point I don't think it's worth the effort of checking the old
kernels which I was missing nor the ones archived with git/git/000.

Also, I noticed that the 3.0 kernel has umask 002 again.

Hoping this helps,
Willy


[-- Attachment #2: 26-report5.txt --]
[-- Type: text/plain, Size: 75333 bytes --]

2.6.0 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1070dd17ae93b86776c166efc73eb18b 97067974e4a490aa533fae78ff7a424c c9e73737002521a347d2e6617beb56cc
2.6.1 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f10b247510edd03159634d9309398e1d 6cc71be409c58ea44f5aec5d52f4de30 fa82d1e4be518261b2eeb78eabf9cca7
2.6.2 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5b23fc3f726335ae8c1946bd2c625a41 f975be5855f0d9aa7dd169ad7febebd2 2a745088acba366f22f8bd3e284a84d4
2.6.3 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5b1837a52ceb92d71583c387d4fabc8f eecc98f673e135f3a7c0f58443f4ce07 6063a7e424355ec52e0cb559fb99034d
2.6.4 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1aa9881e84c4c4f9e0a17c7914ce3605 43638c35be21f58102fb27ae81b439c0 335f06eba1e5372ba38a0d2b253629bd
2.6.5 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5db67c27afb2cfd5d4c52ae1e20f38f4 8eb83dc7ac8608d50086123495af8720 9a76bf64c1151369b250f967d83077aa
2.6.6 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eaf803a496e7b8458ba332b04b89c0c0 f4f8f0f5e67205c366a785b1535bce7f 5218790bc3db41e77a7422969639a9ad
2.6.7 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 104de8f7f6dbf6b84a8089ead4242565 5a1f770ee96b0944added4f7326afc24 a74671ea68b0e3c609e8785ed8497c14
2.6.8 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d14c5dda32e59dad1ace7ebc537cc493 c91448746afc266197fd0da9b3638311 2f8b0030ce970f3c1a460faf5d2b1cec
2.6.8.1 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx deda8b8cf299a39418743e14e58ab8f0 98f93075c7c24e681eaf7e70783af5e4 9517ca999e822b898fbdc7e72796b1aa
2.6.9 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5c715f55156f8979379c8a749c0bfaed 659eaab11678d84c33c6816bd4c6e6ba e921200f074ca97184e150ef5a4af825
2.6.10 002 torvalds torvalds xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 720f5102649c0cfc2c078945fc640feb ec711367f805ffff0e6ee82bc736582e cffcd2919d9c8ef793ce1ac07a440eda
2.6.11 002 torvalds torvalds b390eb0350b4f953a53c16dd5c28810e 6aa8e0b14cdab0757b9474e1a7fb3124 41bb11f9ec307706683c5661f140123e f00fd1b5a80f52baf9d1d83acddfa325
2.6.11.1 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3cf9eae4f95646ae0ffc2d0b83d8868f 6bc1253824cbe6ddc4d39f501b8f8882 971d541176438154f947705d7c5b77cd
2.6.11.2 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f13a1007df661c8e1e37523ab5da1673 147fc341abb88cf1127d98929d4bcfc5 61ade860849e8661f14bd754f5a90986
2.6.11.3 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 12212767ac29e6eea5fd3e839569723d acb17b2519957273da523047e512d15e 9328d85d07e4d02001e0e2ff13a8120d
2.6.11.4 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7259709a5cb8a0b5a48976a320527d48 a9f0512169b0f9158c65632d4cfd1318 f3bdaa6e7e36827347bbfdbcc6c9bc07
2.6.11.5 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 69b34aa9bd308ae09938c7a79f36e939 45e89928a4630c203cdf308382aba56f 94af162c2c5c264344f279c6946c4f59
2.6.11.6 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 068edd6dfc720d7f25511a275afad102 90a33341f6d4d8067de9c33cb8d05c1f 91544ed14e672386bf2f76c94911afe6
2.6.11.7 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7912910e72409daab452a0833db1a848 0fdda93c77077070d81e6880b1cf0933 04f5efb260ff6fb4eaa221fb5b880d8e
2.6.11.8 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7e8b246a232e811c754dadc3ccdb8aa2 042bbb773d055189a3b1bad75a064663 08ef09252e3d1428e69fc011f23b5c70
2.6.11.9 002 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6f4f40d71259fdde0e4b00671768219f 191f324879bc7a9d4ccf866f6ac3c596 e4e23abca482dff11f85119403a703ec
2.6.11.10 022 greg users xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3e66cec82b7246be2b3f49e0faae9e9a 38b1c4956c621d8dbe3d717d0e6ced37 6a66a372a1f8395f241f248f5fe8222a
2.6.11.11 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0e159ca8748e2862c9c069e3e9294cac 21af9bfdf3e49d1b1e208634104dc5d0 d074fe2ef6ccbd635ebc6c327bb82a2b
2.6.11.12 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a655292e4c558d05ebf9cb77d4bfe1da 1fa49d3534cc9b3a3fc97c17b7e8207e 7e3b6e630bb05c1a8c1ba46e010dbe44
2.6.12 022 git git 7d26979a123817f8386c12c5abb0e20d 2fbb5cbd5fe9b57861c6e4167a292613 6050857c0808975dc0ee58bc9804ee20 c5d2a1b62e1dad502c871bba267337d5
2.6.12.1 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b94eb2e6c5039d24a453a95f2e0bd777 343d169f40ffc15a9116aa6cd82e9ea5 542d5aa1657f8da60b41d4d08b098841
2.6.12.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cbec68c32311ea3145017f8f8669d523 ef8385b5a34be8c44d111e9fb3b85fa8 6ee5bf307335e58193c8d2ac0d35677b
2.6.12.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0f4614744cc9e737c41ad6ddbc863627 ab42137978ea1749c485b894ebd48031 21d642266a9a9ce6c73db17605991ac3
2.6.12.4 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a50aec151cb375c6bb446fe2d69fc807 752efdbd3cba5c96109c536d31a6a6cd 5fa86c8e199cf3c08db3b356618d2834
2.6.12.5 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6901d7d629030e24f56a13a7e321446e edcdfd602718ad7282a248cfe60848d3 076f0dc714112c764c790fbaef19e228
2.6.12.6 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 128bc1c572f16cc23e9bda381d507dd4 dc2b54aff74653aa2175d2bfad9fb934 1592bb2a8ec0deb1ff32e8238f25ecc5
2.6.13 022 git git 8ae2c8d9d4f5cab99d4d21019dddf6a4 e0f2e6fe9c81a01b3d69ff4454e0c415 8978c9b3976fae17923ef3e511b54a26 560f5fadf59f172973e67939868a4cae
2.6.13.1 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d30e76b0286f79355041e1fead721a87 88ce10010ed54973122e07e0c8495117 6719cbe5ca5bc916161c825f4ae5b943
2.6.13.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8a62c4b78f7b385d5d5fe0fb402bef39 6b2e04f2ba74552554b606a335d41fd2 6ef3f302348f5b55d0e6e3d53bfbb57b
2.6.13.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 39f7bb153b6718214b0a0b8eb47db48c fe9d89025a343196410d812ab1c8013b 4208271a5a7b273b7bf83cabe2c54cf5
2.6.13.4 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 015640711c8c108732fb4fd0cf693ef0 9f4aab3cddacae3bcc7887a1c90412c9 94768d7eef90a9d8174639b2a7d3f58d
2.6.13.5 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 72a599f2c649c9d6cdda1e61bfd2f06a b0a5e640e8d9c61d311365f5b4e82035 d6ba1208a8ace03e36b432b9ba179177
2.6.14 022 git git 8ee2b4548d71cfa1079ecc2e30723434 9214cedf82c7c5f5639fe40e7c77139a 396029ab7d62bce01122ac50c004a43f 66d02cbd723876c6d69846a067875a22
2.6.14.1 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ef4ba1942a38cdf2625bf9d4e98a22d9 93206b5d82bea0aa5a72cda37fc374a2 df4e4bf5d97a501977a5dbedbcc90a82
2.6.14.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 202e8e48a2a89e223fef1a5fa2c29ba0 aeab2d967a6710339c96a2a16ca9c361 ace4ef323111e6cffbb159a1f5ffc550
2.6.14.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 57fcc3a29faf0e15b3bf85eb68cf783a fc784ab07783c6caa75cab76879bcb0d 982717a9cb246e3c427cc45e3fc86097
2.6.14.4 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx df85eb0756950e685834b69d2584f7d5 dc84028e3f485563213d88c576613ee7 45be19ffe79b2729baf27f7468527e08
2.6.14.5 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4d7e78745ba357e2c5bf131353ca5734 3aaf9adaff17d4e1cd66b067059977ab 9f057e3bd31c50dc48553def01bc8037
2.6.14.6 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 383c9ca1ef8a08d3fb5b942b15728dfd cc4a7f327c69101550a5c09b56716f08 57368527b7e6f3ce072f0da541cca9c6
2.6.14.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 64979b947b941845d3d53fa25dba75d6 762edf1bcf5ecfbc224dae4ea4eb0c40 cdc8b60949f1cea6634fd9cfe9670ada
2.6.15 022 git git 2c970565ab3d24d56501091757359bb8 6adddd15e10f2ff228c70733e2e762b3 873a00a1a20d7ccaad2eedc98109d6e1 cdf95e00f5111e31f78e1d97304d9522
2.6.15.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3621e51fac1197238b31bf832f9a9231 9a967e67e202ba898cec83a88996e63f 3a71f70fecf25a893bb95efaa37f575c
2.6.15.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2b3983c48ca97fb8d0c7a9a8243b9f65 b1296fadb23dcc29b7dc98bbd2fbc419 ed6b6f163f181e677fc07e8de5ed7c56
2.6.15.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 85062656e24b616f57463560db8a1a66 344b3f432d1bcc853da1f11b7fe83561 57a8675485bbc4982e9267fab6b24519
2.6.15.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 58d659ef350b6fa9d4a27a289c7f03fa 14c601838dafa97dc9c1944da2741ef4 cee7c554cec949926cf524ee1def88c9
2.6.15.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 104e212d4ffe20efacb44a2db0656aa1 fdebb0ac2d785c0ebf3e5e4989def0a7 1b9d99238a2f8516101462b37f4679c3
2.6.15.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 15036fa9686a0485f84c6aa682c8af34 171da1d500ab72ba47bb830ebd129e98 2ea7c865d6c09a02cbe6ce5fddcd02ca
2.6.15.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9e372e909c237e537321ca313965811c f788ca2f533b6df65383d9ccaefca225 44659dc87414321340f846e9d26d4047
2.6.16 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e53c27720acee3b64fc10c0ad8d377a3 50695965725367f39007023feac5e256 9a91b2719949ff0856b40bc467fd47be
2.6.16.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3cd78c8412841b6b1ccf246e7bc9f933 51f7ce9d2206c9483cecc1ddfe020e8e 52439ea54fe67b6a0554c01129445118
2.6.16.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 09fb4fce784e09d4575aeb701a5f81a2 ed5211dbddc3d2ec3fe7ceba93b8f3c0 d4105a5ba1d9f82acee2c525c65ef969
2.6.16.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 61292bd2afcdd695aa72f9007681de61 11fae8344ed75b915347f44363ff4148 e8e3f458c72671d8ac041c10b49e2b3f
2.6.16.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8ee3f50d21ccace595dffe58513f68e8 7fbda643e9b81dd5663f3c780d873aac cb675279c9711237a06ebb8379a4da27
2.6.16.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 918b457de742485c5f508314fde78a24 9bc201e9e0153365f5f63d0b94a921ed 45ef23c209bed21ff3d44eb8bb48232f
2.6.16.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0737c9c3d87d07e8837b77f091edc502 1a0d4faaa51e5eabeebff3ddda3d1837 12a7d9de853f8c8f43b790bf4820b195
2.6.16.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f4be3eb6fffb1168af41c78ff2f99071 f523449a045710dd1e4da04895a8f000 9682b2bd6e02f3087982d7c3f5ba824e
2.6.16.8 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 92806f840fddc9ab5768d595d3e352fe 26a90f42900e8aed368f155367128c7b 62023a6c29efe6a3cfa670bb8dbab72c
2.6.16.9 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f3587bea8e2da0a6b67653c980683d7a 53207b81f5fceccc3ee2b4dcd663be94 d1b670c17c1dd49ddc614e480df0ec73
2.6.16.10 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4ddbc90592f131b17b237e8887fe65fb 2d6d2d5c43fa2c364fffba06205eed9a fa033b62ca83b51ce016adab195aabe6
2.6.16.11 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 98dfc9b771c9db10909484a781d40e8b 4e1454a3ee75e6112d74ba9faa91986c 0854d832be6227fd757f75ae018ba8c7
2.6.16.12 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d4a430a76d9c8102ebc79c60e062a253 582a768169afb9a45f29895d86bd439e 93bfa0f0454c368be5fbb6ed71ce5c55
2.6.16.13 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f2abe5ce6691b781af3be894b985732e 54d5ccce923bf67bf76a1bbd72a409f4 3101894807968d4651b54d9f61d9e5a4
2.6.16.14 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4db2da1881b5b23cd8edb395defa27c2 f454df464fd8f0c4a71b50ef55921679 4b92c1dceb115e01116bdfd11e027254
2.6.16.15 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 893b765dc02209a77e064d963a236c72 c7be68856faee83084ec9ff730f021fa 472e74ad57f31eca68044a1bb74e0496
2.6.16.16 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9d73f2a7c86ec3d5b2443f8842569415 6b17c4b73e32a60092e87cf223b0fe0c dfb066db24a8a9b36358fb290cb06959
2.6.16.17 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 653d42331c3c242c06899cc699578115 730a6267bed2845a4ca41008d4ad4f28 91a30e391b6dd1dcf71be43fd4271d36
2.6.16.18 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9941a35299816326a2e56d3167a43f0a 1e9cc3c5b419fdbd92385fca1031ffac 5cb158630f9615983ab32cea9ace3025
2.6.16.19 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fd2b44e8877ca4adb776175fed981e00 318b60c5851f4d5a0a2911f4796bd96c b1e3c65992b0049fdbee825eb2a856af
2.6.16.20 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0ea4c0c8ace3da39c28a2125b99ce4ee 46f4386dc5b0cf5fdbd3344ff745e351 382aa4178ff79d58925622a8a97561eb
2.6.16.21 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c34aea20cd263b50537c902ec8fcf3c4 04518cd185013e3f2616d4785f1d691f 74a0ec53b3cca229e85985f61d1ee894
2.6.16.22 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fbb6fa23634c3ecbd53f0905a5d6ced0 a0252f453e0b94e6dd4ade36f8e957eb 5897fe9162a191006be821d570f55ff1
2.6.16.23 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 17235eb4b092924ae1e4e411e24e30c9 aae2e26b7737a641a5e39790de423601 e17dc74792838545679c159fce8fa2b0
2.6.16.24 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2ddc69d687e87ce1f3fff59bf6487443 3e5f3bac6a02920c96cc13705135f176 a80eb039c9f75cd13c0654defaa94380
2.6.16.25 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx acf15c7189bf83089b778e8bcaa53371 7d5d484397392a413c9e0cfa373fd90a e6e16cad21f1226dd7a31947c7c5c4db
2.6.16.26 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 061f38240cb4465a33c08ec678e6e1d0 30e64749aa292414a30e281276763a4c e50cea2dbc4f427b4b555b8e0f77337d
2.6.16.27 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eae7fa6cebd25129aeb036ae53606931 38e0b035137d7a50f672005c7b445e71 ebedfe5376efec483ce12c1629c7a5b1
2.6.16.28 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1637cf0ea3820166e4ccfd8576679ac4 06cfc319751d5d4c5efd7cc58d08e877 fecb2984385eb0eaed64a40aa9b9eba0
2.6.16.29 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4424d11ae548cffb550119d4c40543b1 589ed3abde57af7ba0761b74c0e2068c a114d4853317b784ee6e88f35d5fc1aa
2.6.16.30 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e54ee761cdc9df4447510141d03fb78d 48fc20d86fad36fc8ecea7827c8f8308 4cdd9099ec73b09706eb136ee836f92f
2.6.16.31 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 51452567b0bdffb973b3a25599ad870a b060b31b1553bd0f4899f919bc75c101 21c88c969d482140d929ba373cfc8a30
2.6.16.32 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 98093b4b3f6e57c8b227c733b98a9ad6 dd5f65278012c6e0b335ca3892a30997 47e0db0a20cba50751d6865ab6319a8f
2.6.16.33 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 38ba91f191eefcf2a6d038cd374812e7 47f50c1cf16a7aeb977f9cfffff9eee1 22f56e3a5e7524b2bbde2696152b5ad7
2.6.16.34 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a0ae34be62515f1257e32e7008a88871 a22c4301e6d1796b8454509e31525ee9 fc5c4ed88ce5c036a29d3c5a4c4b905b
2.6.16.35 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f50ae18066b2684f6ea11f970039ec6a 2600c6130008afcae818ab9e095207e7 87e383c1446a7e4cb4c919145eb918ce
2.6.16.36 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f3692397cd3586e56f9f5151b33b8620 7abac83f300c493b9513bb7dfc00b040 a7337e8c1dab21b2bcda717978ac6533
2.6.16.37 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 64c43e3cbf9d31e8d7ad272db1463a1f a57838e4ecd6ecb7e64fdec18829e17d 0bfeb891c927cb8204ff9f40ad305655
2.6.16.38 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fdb2ab6866ebd6dff042c1d9aa01751d ca100ed2fe6199f274656702ecc03dbf 4ce97d0f4728d9864c91807f47128deb
2.6.16.39 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ee3e5b3193a69fffd8347bdf413c5cf6 d552b34038a680a6bd90e0b79ad433ca 8d9ed441f9d349e8257b873539d934df
2.6.16.40 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e77c3d4f66df6458217e4dc47b4d2313 dedfe569626664f99e97ff7de5098fb9 6814a055e67b4f7d55e179edb04e6b9f
2.6.16.41 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4d6f616d41d2fc0c1715b21e2b84d1be 2ae13e241821514e460a2b643f75b499 ee399493ff2ac5664618ea707fa4422e
2.6.16.42 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 55eaa70ab3b5b2cccb968b15e69e9d52 4e0c9eaebd041f43924d8c4a6b3df43c 87e998bb87839b962702815dd5aecc73
2.6.16.43 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3769304f6058796a56e20ab8407e6846 a18293482bbe59f89a68b0b52ca03ef9 f818e246ae2901fdfa3e5356c426302b
2.6.16.44 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f1082d194bebec928837f9aff1451e0b c7f4a9003163009ad288b9b0fc752db0 3d4cac27e003dda881e4c891f38b4e20
2.6.16.45 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e09dcf0597149a4a191e3e5f5fac8d62 03fdf51f5f9e79e2b03630e5160fc254 99a372cdbaa6707703f12ed7b6affe21
2.6.16.46 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9be83fb732d626e93662e12d1383e01f a1f61fc4989b979460922d06893aba2e 182cd44cc304fea4cd284e75ff4ca4ec
2.6.16.47 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 32d09b699c7b370a2528122dc25feefc 1cae98732d1337c72f5c9f6f94fc1820 7230c4411375f88d9119e81d6043c22b
2.6.16.48 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f661ed4d436ae4814c36e86672b487c3 ad574b297d493ff29eb28959b50ab250 21cf770dca6c233659711011a129de79
2.6.16.49 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx dfee9ff61e6900db6d3c0bda83251420 a0ba0081813721163143bd6f751664f6 0fe3ec42bfb3a69c9489137a482df63d
2.6.16.50 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 219c23a215e72060cc1ecc2ae3d5e6bd 29d67ef797918d787c99cfb86cabbbe5 cc2106c6188675187d636aa518b04958
2.6.16.51 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ca1cb3f3318444aaf0a2fb8750d4ce67 49dc39e7e13718c9da014c12b0f4c86a 5051dc22b93880d939fd03c1ca9f7272
2.6.16.52 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1d81e44a2f617025755b1612fa590df5 ab4c67469172858a7ffbdcd7dd52b77e 7f1ceb334f612f1280ee9a0d57faac64
2.6.16.53 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 73411eea5a3ee1413e1d9536179ae0e0 f3eb93808b76a527ac8c3527d868a9b5 5c6e965d9121ba0d3f3c747e519de402
2.6.16.54 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 13a499be8c6696118435e07873bd7d1f c017c3d7b22c062b8be5937a50180933 6d63369a98736bbdf0ee52f3117ae9e0
2.6.16.55 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 08f48e58130e2893f236d7fbf613c2e2 48184b5ad63a9d9ceef80dea1c88db9f 9885a7f67480b5a75ed80c06b1906874
2.6.16.56 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 33645decda14080d81a9f7102a3a9c98 7eda8b474155c8e68f441c4348d0d57d 2733ea1e0f924402da4f6903cc38bae9
2.6.16.57 022 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e282c0992feab273bcb2519e7eb2a117 db92df5e0b54431ab88555bd7a4326ca d6f37a2967be44ab2696eef3132d4b0a
2.6.16.58 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 5d3376fb90484d6ca7986462a6089195 bc6cc7d08b521ca4da71f06b5ec74073 91ce734d2f6d3d402d2d306397982101
2.6.16.59 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b5717d5c10760b1da2acef53e7748be3 d3f4995f26b06030ce4a0362d0eaf645 9fa89a490d8c207c26e44187071b5144
2.6.16.60 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 92426ba59ff88c2e0ce7746cff8a8399 6a94e7a89b622cadb4c1fe6fc86fafa5 551970a317e9573f9ab2a9bde647d00c
2.6.16.61 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f1cf5204b63d1f6182e5988215dd6286 ffec9c0df8273547d1209183fdc64a81 c5a87bc9804f8e2edd5ee24e1084d59c
2.6.16.62 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ecca3790043699f681a708e475c2c3ef a90828ab516f8f1ef1b9afede76baa4a ab4c42da260c9023db3ef32b659296d8
2.6.17 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e9bc6b98374a3a05d6ed81f3a9cfd72e 3ee4dae7b648e9c290f16fcfb368dbb0 37ddefe96625502161f075b9d907f21e
2.6.17.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 533ba20ac908e0238399da293f48dd54 28e927078c6c7e7437bf7e02bf7586bb 0a8f1a66646bc6ac7b3ec3e8f51652a0
2.6.17.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 14a2ef0b72f9e45d868542e5eab58e8e 96c979b9c353032072c3d612f3a6e533 ceaf900cac37616f21135a255e753a19
2.6.17.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 082c624894951abd65fdeeced087d962 086e35843037da099900e5e5575d0aaa 14bcbbbb4206ff8ec863f9f3aa21293d
2.6.17.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 50b80dde882295df16f7471fff48380b d0d78b8b9e9e1a7f250ba1fc39a3959d d33826d07134d33e526f3e828af24287
2.6.17.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8c15c132ae154db002a63e71c3e6bd56 664fb2aa1bdcf22ea436ea6558277b9a 7db2d258700c135bf490c4ea63edafe3
2.6.17.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aaf65bd8d23aabdf75ddd406a9646bc6 f0220345b7b0426d2f088c2f2cd294c1 5013fbe6049e32675187c203aef92218
2.6.17.7 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ecda5cbbe914f94d2bed8848ae9a4968 5a06690dd5663eae2907b61590c5c703 cca7d49341ef1aa51135bee56c8cf3e2
2.6.17.8 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 27e3048e504c7f76f221542b7aa90e71 6d4a92263e2a7c981229bb9b79c35215 eeb862ed0ad868ac458492cbc60b8112
2.6.17.9 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4fa552b025c43675d7f78cd377281daa f0709af5163d1862fdd9c2e0a806bc81 f7a5b1aedb5b44f4df005caa5f4cceb6
2.6.17.10 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d2ded9e14f0de702b5af8a3a7ae7106c 7b283d099d5149d81a32040c91eae6d7 cb803b920433a680c4cdafcb3b0f18d5
2.6.17.11 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 28425b5d774d23a213858763dce32b0c 691637e82c46321322c9d0e9683afb6d 2958a620129c442a8ba3a665ea34ca8b
2.6.17.12 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 23c1449971ba8dcbcac6e6756609de11 33755004fb8ff86a5780b12ba731e032 527fb3a259a7ec9cc2107b8cbcb7150e
2.6.17.13 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6fd82a0680b10b55d29cb3430c3b3b91 3a82892b0aed02d60bbd43bbc25c345f 834885b3ad9988b966570bee92459572
2.6.17.14 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 242b1f18c6f0f569515da596e5b95de1 55473011ddeba627623a2e79eae51478 e721b38e8827f74ca517f5ad617c1db7
2.6.18 022 git git fa24e3245d8cb475ebffba763912063c ad43dd75219d9e6a8a9460bbf5f65b3e bc483723670bda09198d72293e712d42 296a6d150d260144639c3664d127d174
2.6.18.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 387e945caaf4ffc07f53259f7dc11d72 c06781ec858300b6075a98a6dd075296 38f00633b02f07819d17bcd87d03eb3a
2.6.18.2 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a5d03c75d8abae325a709fd17f670a98 33deb7218df7d4407b562a2a08ba56ae a93293f01307c47589ebdcafea311c66
2.6.18.3 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 301f0e1f08d1f055230f5fefd183d84c 6357a0844ac055f63c52f6b726d6d13c fb10bd4918f22f349131af0b5121b70e
2.6.18.4 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aad664fe67f3bc95be6335bf7209380a e2c672cf071c75c8bebd5f599e6a07fb 05fcab267befd41e7e48ec2fc6dd4a68
2.6.18.5 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8bb3b1c18f7a4da706fb59b550d99df9 a03655c1bb317c54b448ece6cecc67b2 df0dda87ec37de5505aacf6163db79a9
2.6.18.6 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fdd56a2874cf75a87061a7835e3657f3 76d0c0656a470498d58a4b1fe228b9c8 80812ae14dca35b3630883a96531674e
2.6.18.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 369610db40fc895b615b3995709051fc 1ed8fd27be96085e1b0047d3773fdd9a 1fb48ad0fc6159491e5ce70a11d83400
2.6.18.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 519f4e1301abd30ff02e1e4c46cf5cc4 8f0e54c3afec1421e743a35f5a07addd dce47badc1faf34b355a10b97ae5d391
2.6.19 022 git git 2630dcec21807a23b8f3c1d3463a9537 be8a46187734cdb911bb4aa37f864f5a 267a9479c6c6a79a0b2f511ddcc17147 443c265b57e87eadc0c677c3acc37e20
2.6.19.1 000 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bfffe69dabc04e2d6a7424be578cb5e4 636e33097b22f6d57de5c7e0a8394d12 2ab08fdfddc00e09b3d5bc7397d3c8be
2.6.19.2 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c0e23fc100d216497e274e0623640495 ca51612e0055bece7e1b016dede1cfba ca0ce8f288e8ae93ac243b568f906bf8
2.6.19.3 022 git git xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fe29f6e16d8708b2cba2f0e457cef093 1e0532b214dfbd841d66ecb57b17c281 2439f1889712eaa8a0755942ee869fd5
2.6.19.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2fea910d90d6f8be6b1d43378f6edf64 33290887f0854cedf180e8ff07afe133 21fc8bcddf29f4bd3d010859ea0e4fd8
2.6.19.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d09e08774b337128e440e05ceeceae1c 3f436ebe67bc5ce9f5f8f2aaaf43697d 18d23da151acfc834c9a562d3be4024f
2.6.19.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eb845873b0f7ed3c3517daeb5967e19d 91bb72c73ee1f004511e06e9d2181139 fa3eecd3f7843bf671b446d7553bd880
2.6.19.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b7ce869b1fb9a60322b164a03c8cf388 453585d5cee3b534887ed6c1e5fe9590 1cffcf2f40370acb6d0abe90a891a17c
2.6.20 022 root root 1c3a2b5f69f773e1ce3f02b0f3abddfa 1c3a2b5f69f773e1ce3f02b0f3abddfa 38b0d6ac20164a53cdab54f0039aeaf7 34b0f354819217e6a345f48ebbd8f13e GOOD
2.6.20.1 002 root root c550ea5cee783951006450caa3dd3f95 c550ea5cee783951006450caa3dd3f95 8de9e67a66fd6e32623be16bff67866f 3288ad6c10ba89e85041a8416bd9644d GOOD
2.6.20.2 002 root root 61056db1f9194d0a153ece9572200b4a 61056db1f9194d0a153ece9572200b4a 24a8bfbc022ebf729a6fde2d399bbbc4 bc33bd163130df9c59b165a1d31ccfdc GOOD
2.6.20.3 002 root root 32820a679e81cdeb454f54d0994cf968 32820a679e81cdeb454f54d0994cf968 ed5a2b5870e5259535c46fe2b51a59d2 50541e43ec8b9861e63d2351e5355703 GOOD
2.6.20.4 002 root root dda6d62ecfcfd5d0f2d7ae9bd1107b6b dda6d62ecfcfd5d0f2d7ae9bd1107b6b 50588c7d6273ad481fdd26fa9ce25f9d ad6df0431ce9eb91dd558538e71239de GOOD
2.6.20.5 002 root root c39381da208d5c15a2710673df5654fc c39381da208d5c15a2710673df5654fc ff77928d030af8200ad48d90e249b8cc c692bf208707fcc71943a66867d1edd3 GOOD
2.6.20.6 022 git git 4300abbeb91cc50b48c086c2c329eab8 a4acbfe6fc54823d96dc257a2595257f fdd2e0336ec063cb8f6a4f36b0a3d257 dc2f9b8c76d75802d39ad2a99de587d9
2.6.20.7 002 root root 4352dedea3918d2c7d3a059bb00aa580 4352dedea3918d2c7d3a059bb00aa580 429632d5efc6c90759c301652cddcc58 ee568778eb50a5bccad8915ce0a72e7d GOOD
2.6.20.8 002 root root b26f5458b175e3b935586c433aa82c8d b26f5458b175e3b935586c433aa82c8d 04ecc74a2ed79afd267c9c07755ba74a ea3c71b36fe1c835ffd817197199b8c1 GOOD
2.6.20.9 002 root root 12bf096a9ec27317a7fd0bf5241aa86d 12bf096a9ec27317a7fd0bf5241aa86d 125778f04354ac2e745499b58cf7d6ba 49ca303ce62534165161b0e7d33aee2d GOOD
2.6.20.10 002 root root 3865227516b1ed115dcf52eda4ff1ad8 3865227516b1ed115dcf52eda4ff1ad8 689ce2cb0737cd95826fc7126c70626a 3ff197ae590d089646e9e68de3456ec1 GOOD
2.6.20.11 002 root root 235e4c9dda5c423ac3ccd3aee7587553 235e4c9dda5c423ac3ccd3aee7587553 0f6a91c70002e2cfd0c0a6ce17444d8b 471c06e8a9c11e556e7e38e49c6f2f52 GOOD
2.6.20.12 002 root root 8d9cc27403c29355549998b7966d6350 8d9cc27403c29355549998b7966d6350 02713c1f806436dba157c15e8b8802e2 1c4e5df053bdf4d1dd46064770129382 GOOD
2.6.20.13 002 root root 7331349a0e0fe5dbd230fb10900846f4 7331349a0e0fe5dbd230fb10900846f4 5d79938dd836d09ad3a5d158e374cf8a cb417e7ac0ef4e257b93159028823136 GOOD
2.6.20.14 002 root root 8e7be87759f3ead0852137e366c34a90 8e7be87759f3ead0852137e366c34a90 291ef875f6787af051ee943134443cb2 63deab5998064e93196c0b75e77060f0 GOOD
2.6.20.15 002 root root 7bad3d284c2cbbaed0d2338f81e76859 7bad3d284c2cbbaed0d2338f81e76859 e3ce8fc41c019a0baa05e0b8318745dd 550c9bc15b9c9bdc2a481b08f5459261 GOOD
2.6.20.16 002 root root 25a1013fabd489d302f71bf3cb1837b3 25a1013fabd489d302f71bf3cb1837b3 e9c78f6182b83f68b0f654ed6837ce5d 9f449e8876c948a18e9d45a48e17f408 GOOD
2.6.20.17 002 root root 5259b132a710eacc1e7489129f3b9e0f 5259b132a710eacc1e7489129f3b9e0f de390b611f39658ab89c8b519b0daf97 2d3eb0cd555637f2b2aef51dacce23ab GOOD
2.6.20.18 002 root root 4af3439c081f86b68a30d0bd447179c3 4af3439c081f86b68a30d0bd447179c3 e7189e95ef81cae9eb8b65d4aa828e98 af1334593180ea6540bf256d1ce596ba GOOD
2.6.20.19 002 root root 8bee08600da3f46bce0d2f15b1e3b68e 8bee08600da3f46bce0d2f15b1e3b68e facb801a1653ec6a8b856032d1f03a1a a00d77305866b6b767291383d4b28132 GOOD
2.6.20.20 002 root root eb1b62690aa859f6d1deb70695e253a0 eb1b62690aa859f6d1deb70695e253a0 d9c84f85036c1d8745661485d484d61f b2562ee2480ab3618a9cc56f796825ac GOOD
2.6.20.21 002 root root f85b1a1337f825832d1b39d1c62f457f f85b1a1337f825832d1b39d1c62f457f ecb03f520bb06be2d01b2e6258e2d346 fbedc192e654735936cc780da8deeba4 GOOD
2.6.21 022 root root 7965f0be6b6c1a4ff4e34336ba25d975 7965f0be6b6c1a4ff4e34336ba25d975 76eb5308dfc7d9ab70534378af379c09 1b515f588078dfa7f4bab2634bd17e80 GOOD
2.6.21.1 002 root root c081d29d0c6ff1b61fd962b8259ecbc6 c081d29d0c6ff1b61fd962b8259ecbc6 c1e64db8f384a00c19e9a23d0401cadc a28b78793cd368592f7873bf36cb38b0 GOOD
2.6.21.2 002 root root 78d892b513b1b323ad12e3d3c69f6dbb 78d892b513b1b323ad12e3d3c69f6dbb 862039fcc0a679bd7e387cccda47e5d9 95dfe921a0749a613e2e1aa1d389577d GOOD
2.6.21.3 002 root root 26b27b1aacaac870c94c3ce14155489c 26b27b1aacaac870c94c3ce14155489c c7815d473e630780ab10c582c7809c0e dd25a51e9efbc13111abe45912895080 GOOD
2.6.21.4 002 root root 562dbfe628d7f4ec5be02f2eee444209 562dbfe628d7f4ec5be02f2eee444209 82cca4d22dd920c2f22159e5c3d7f4e6 c50995d713ba2d73f148e10073342568 GOOD
2.6.21.5 002 root root 4c778ee298cba1ba82d8f8ec00959f3d 4c778ee298cba1ba82d8f8ec00959f3d 227d5508dc23bc487d0a5248e690fbb1 2e9a302b5d514b231640227d6a2ab7bf GOOD
2.6.21.6 002 root root 3fc9cbc5f1eabdb79f0f819785aa79ee 3fc9cbc5f1eabdb79f0f819785aa79ee 51cc7a0f3fdda8aa1c510791c5bc152e 8f27a934b47b199bd0a1abe57a5005f2 GOOD
2.6.21.7 002 root root d4efe4b192ca2be608b75a881ebca902 d4efe4b192ca2be608b75a881ebca902 66344cad74e92c6226bea32215816ab4 bc15fad1487336d5dcb0945cd039d8ed GOOD
2.6.22 022 root root 2edfd190ac09c0e5b998ab8514488cfa 2edfd190ac09c0e5b998ab8514488cfa c98e1329975a8a7931ae63bafe39b63a 2e230d005c002fb3d38a3ca07c0200d0 GOOD
2.6.22.1 002 root root 93e4955063c604799affa171cb6370d4 93e4955063c604799affa171cb6370d4 1ed7fa45fd8ac8faf19f5f48dbe54e9c 50249e822a2a112d9221129a4a3af374 GOOD
2.6.22.2 002 root root 5af3437e6ff97f9920d227681f1c7b5e 5af3437e6ff97f9920d227681f1c7b5e 296d36f688f82dff934a98e05e1dc5fe 3dd27284fea13e46fc2e110e3cd8a72c GOOD
2.6.22.3 002 root root 65e5a5d73e732ef3657554b2eeeb3547 65e5a5d73e732ef3657554b2eeeb3547 54dc78c7d23e3e2272ec15b8caa3307f 13dd3e1fff368190a4d4be8838016880 GOOD
2.6.22.4 002 root root d2294a1e23ef416c0b03cfb84acccd3f d2294a1e23ef416c0b03cfb84acccd3f 1b57bf74df8ee5b2078a33c41fe578f5 6cf83acf21e65dcea4a5170c0bbc7125 GOOD
2.6.22.5 002 root root 34bfb927e95b7645ecace1becf492b09 34bfb927e95b7645ecace1becf492b09 5077c04dfe5aa3c55e5b77e13a0b2e23 f36616d74f2fde72040bccf50db03522 GOOD
2.6.22.6 002 root root a610d656962ebfbd46efd96ce0a96c66 a610d656962ebfbd46efd96ce0a96c66 155cf629abc4215744c711f0773fefba 20af4d1e05bd725e89b691da483276e9 GOOD
2.6.22.7 002 root root d89f77ec176b0eab0be04ecdd06c1a2f d89f77ec176b0eab0be04ecdd06c1a2f ff8d5fa0f97e5f39e3ad3f95b3b18365 dfdb55347ba98f4131c3458d26d4e5fc GOOD
2.6.22.8 002 root root 3b49a858cd506f320fa24adcec47c8ab 3b49a858cd506f320fa24adcec47c8ab 0fbfc23579850a8869fd2d98671bf5d3 ecff2126dc440913303886978fb0cae7 GOOD
2.6.22.9 002 root root db2827199bfa42595a25bdad5e6fe500 db2827199bfa42595a25bdad5e6fe500 c23aef37928a4167ccc0cdf4ffb2d6b7 ed31585b9f5da6edfc6f54c74e736775 GOOD
2.6.22.10 002 root root 2dc8fd7f16668e1997a74a1e731febe6 2dc8fd7f16668e1997a74a1e731febe6 c4f54241f11bb4b9067ca78036dcaae5 de5c6142413a49ca96832841b1aca8e3 GOOD
2.6.22.11 002 root root 57eb4df5f3863be6c6be405eb8a97c1a 57eb4df5f3863be6c6be405eb8a97c1a bb72d4eb74bbb1b77f121e43cf9a2c50 497ab35cf8ab65bf7c4287ba7bea3128 GOOD
2.6.22.12 002 root root 055c7b258abb9489dbced86537c7dc4e 055c7b258abb9489dbced86537c7dc4e 6fb1dc14cf4e432fc8ab208bb532cee4 dee9596ce5d0ae168470a8cfbd99f866 GOOD
2.6.22.13 002 root root c1f411391548652149ea78afd7ffd026 c1f411391548652149ea78afd7ffd026 eb1d0f88827dd076df6ed2c8c3dbe670 bf3d29dec769b33477077a92d50d102b GOOD
2.6.22.14 002 root root ee15acfef4c0e9b787816546129c34a8 ee15acfef4c0e9b787816546129c34a8 cb29d02fdde2d7c3fe1337d94d629753 e6a50c93b5a5803e9e09d58b903c79a3 GOOD
2.6.22.15 002 root root 159067c422109e1b56e43fdf34e049f7 159067c422109e1b56e43fdf34e049f7 d66f9c0b68ec9e8001dd98d262dc7c15 e4303364ceb434bcc3f46ca9e4fca67e GOOD
2.6.22.16 002 root root cf84f4aca3f11062968b5ce2351560c3 cf84f4aca3f11062968b5ce2351560c3 006ce66ee6763320f1309f29bfb1cae2 e2600b6f28723cbb610279a1fa668cd8 GOOD
2.6.22.17 002 root root 18a6b5c1759d2ed3d2552767d76329a0 18a6b5c1759d2ed3d2552767d76329a0 856368e29051f667b573b5377c410fa3 0ea4d8553511abc74647c63300dbd3fc GOOD
2.6.22.18 002 root root b64d9b8f3c050692538ec941cc6ffd2c b64d9b8f3c050692538ec941cc6ffd2c 7ce91fc94a08dcca16997313f3af7ec4 bd375d5885bf114c74a2216d52d86e34 GOOD
2.6.22.19 002 root root 5d5f55c4a794af96dfb7de2114755bba 5d5f55c4a794af96dfb7de2114755bba 99f756bbbc303b7e75eced5116b916bc 4db27facb78aeb79d06e6ae6bf0ac0b6 GOOD
2.6.23 022 root root 853c87de6fe51e57a0b10eb4dbb12113 853c87de6fe51e57a0b10eb4dbb12113 46434575a50b8d93ec04fae80fc5e890 2cc2fd4d521dc5d7cfce0d8a9d1b3472 GOOD
2.6.23.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e0fdc51eab8cd05095a79933b1f7dd67 13406ba7dfd3d9ffb6efdea03336d0c4 518d57e08fdacd88907166a3bfe383b7
2.6.23.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7d8932c757e420c8d5e50f1be9c2411e c54bc9c3fe525ba3315db1cdf790ddbc bf75aecb76d2b8636055e05084516ac9
2.6.23.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b36557355d75131f193df548978a1ee1 de3ad48cb264e06c7c2fe7b02cb83f7b 3f41b9714835b264e7d9483f2496feb8
2.6.23.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c3c0824b2c0e1b468eb4866edddc09ff 79f1de0679903f433f2844538e3ccfbb 5781ee91884bfca0d59c9222c0a76f29
2.6.23.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4630320a2c99bac78c2af3324ce33117 3d3de47b19f46dc01e1e449935edaf31 d5dee267a2b2237d1ce34d891759741e
2.6.23.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a01191548f580df59157cf273dcbe607 90a759bc2f04b8e5e8e306784c113e78 dd63cfd40e18fbd8e520bc2d224acda5
2.6.23.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 531e7bb89441309e2a79106bfc28dfbf 35d83826fcf45820ffa678f2eda3cac9 0fcfa54e8cbbde5c08fe62f8c2952392
2.6.23.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7ad20e137963543c46f4402c79accb1b 7b591da5db63cf9910c0eea6a79cbd3a 2a8895d7e91f4ab7b3c582d8840fe685
2.6.23.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 07c1c75a34bf2cb2517dce78491c2236 dd6d45e2b8d965cd013647ebf3b97f6d fc341e4f23bcd4056bdb0c9edc24ea3d
2.6.23.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ac0da020542a014f8339bd85f520db65 6ec1ee797f5b6bb5f7cddae932df372f 845138753b0346438a2a2089d8567335
2.6.23.11 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d1807eb886104772ec5721b401d04171 b33625c16a5fe6f29273b4a3fefb0e17 b9e18a02297ee556cac26d65f25e0ccf
2.6.23.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e509962afd2040b4a9dcb88e8dac2d93 527918effc9b8a40b5b15219091d3330 815b2f90b3a61919014cbc6d011fa9c6
2.6.23.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f70e0e9215c751238945e0d65f0bedc6 536b1e209bfe0211928df53e92b577e6 cdf1ebc7ecb40729181fb09ebc3e17c8
2.6.23.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 81d2f44218efa76b849f8d874109395d 763b59f98bf021f2766de996f819d5f2 63a6a28ad2480edcffbc09c008b0939d
2.6.23.15 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 17b289e417f49cfcb9212d0e8f00ce0b eb0fec1f46afebb2454d2dcf222aa0bf 899067480ab281aa95c8fbb892c769f8
2.6.23.16 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 14d58be1fdcccb7456eecb887be9e0f8 d87f8215080c53d5403eb26dc99d3242 2637a7f1d4450bc5e27422f307fc6529
2.6.23.17 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 09c584d8c89f07468703b6a7eeefe147 f36af6492489b0ca8b7ba13ded8872a6 a0300a393ac91ce9c64bf31522b45e2e
2.6.24 022 root root 19aee46bdd4577a4ba14ba51284cf791 19aee46bdd4577a4ba14ba51284cf791 f09806748f6809d5f7d2a1859240e1a5 3f23ad4b69d0a552042d1ed0f4399857 GOOD
2.6.24.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fd5d1ca4b097581b7ee67a98212d210e 83e184f27ae53ea14e841af0344e6d85 c726942cd8d1f3205767ae45f4c9fbac
2.6.24.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cef2840c958447ef2e00dbdcb638ba17 e4aad2f8c445505cbbfa92864f5941ab dd573a2fae55624ed92fa49c17583964
2.6.24.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 75cd7750aad7787a1c646988b717da74 facf544191ca836a309ee960eda3a80d bb3f3af4d8feb3b81a2f14aa90186316
2.6.24.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fc2c8bc930292b6d3ba164374bf65c98 71093ee1daa3e0843b48492d54113f33 91d3ae8d362c8da73a0aa17d5452207d
2.6.24.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c434ef910d81ab954e212f82d89ede63 21360e644d0feeb259793f86b7295f0b 26500f8f92895bd33e391088b5edd4ad
2.6.24.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3abb0224ab760b595b86822d0436c237 eedd24c3642f0788a742e1b996119fda 95415b8e7410499303ffb2c4464604b9
2.6.24.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6305363b40d4e2d44c468133c8290f99 30f254a65227fe388aff8abfe8456a1b 40a73780d51525d28d36dec852c680c4
2.6.25 022 root root 2b8b848fcae4e1d4fb56c897e3a40c21 2b8b848fcae4e1d4fb56c897e3a40c21 49365ebfea0d5d216f4da597c3e28f9f db95a49a656a3247d4995a797d333153 GOOD
2.6.25.1 002 root root ca288f8d0a47a31a2007da996212dace ca288f8d0a47a31a2007da996212dace c83890a56cac5e49ad2acba50f3c737f 0d26fcafa00dc5cf27d4bf01301409a0 GOOD
2.6.25.2 002 root root 5199cfe55c13162661ec4035272e072d 5199cfe55c13162661ec4035272e072d 23148e8640d9dc48bbead012eff4244b 007f941d11744f20b8849111536b19ed GOOD
2.6.25.3 002 root root 5857b5bb21fe8d41460e89b87b9f5362 5857b5bb21fe8d41460e89b87b9f5362 049eeb232ff9a2e239f2029b91bf8476 39515484f39578a5565faceabc5e6c25 GOOD
2.6.25.4 002 root root e64c0ae28293e0c578a029af170150d2 e64c0ae28293e0c578a029af170150d2 b7509c03baf2d842556765eb19982d6f c2ec5007ee62e1b1ab05a1ca9155ebd3 GOOD
2.6.25.5 002 root root 828cad924870acb9643bf4bb0f72cc92 828cad924870acb9643bf4bb0f72cc92 dade9663f31ffe08c36271132835a004 ecbb7bb3e58e6d1fc86c6fb337a2dd95 GOOD
2.6.25.6 002 root root 6e0ee8c95c9aa2b619dd9159c1eab57d 6e0ee8c95c9aa2b619dd9159c1eab57d 98500db8178718c51ed6b242d9b1ed6c 82f641f5774221bbc27dbd83a31c88f6 GOOD
2.6.25.7 002 root root 9ccdda12b747a122a94ac30e735ba9f9 9ccdda12b747a122a94ac30e735ba9f9 9a716afe867443cf2ea20d425a79a7f6 783551769cd104de0eac19bd78dc5ad7 GOOD
2.6.25.8 002 root root b1adac6690deea86340d5e18fd7bee7c b1adac6690deea86340d5e18fd7bee7c 3d9fd797d68e5786236a817200439833 de86aeb5da7c95350140cbd7248dcaa1 GOOD
2.6.25.9 002 root root b737d23e536e7f9bd93a5888656c6a87 b737d23e536e7f9bd93a5888656c6a87 6efa1677d919a341d2fc6e65df306976 3043ac42f3829701079fc16df04c313d GOOD
2.6.25.10 002 root root 29fbcbf3fa504b000e6b405c681e91eb 29fbcbf3fa504b000e6b405c681e91eb 0645ab9c54b04ff11d09a949432cabec a6b0aa5b1fa1ae5a02a7b67345f01e86 GOOD
2.6.25.11 002 root root 225c43654b864c303822385572e8df9d 225c43654b864c303822385572e8df9d cfdb2fdee18d1801939e995da01df804 0cada52b3d40a0456252033e7dd33697 GOOD
2.6.25.12 002 root root f5d46c6ae6d2a97f8d54610d8a71665b f5d46c6ae6d2a97f8d54610d8a71665b bd25fe05a9a67f0208a2bae486fa5cac 7c413ecf94a84776aaec6ada5694318c GOOD
2.6.25.13 002 root root d2affb4524db60f4e0c8c79a01fc565b d2affb4524db60f4e0c8c79a01fc565b de9e88a477558d163b0d9f21ba709880 ba05f43172e3bc676f5fbc1a9a75e816 GOOD
2.6.25.14 002 root root 39380a57e0d2826acc72e16e0d0bbe86 39380a57e0d2826acc72e16e0d0bbe86 2e64c858b2dd1fb276ee752040ed75e7 b258c1e812622c6ade276057fb885911 GOOD
2.6.25.15 002 root root 32c56b46350368ca97f0afc4dc291e4d 32c56b46350368ca97f0afc4dc291e4d bb916acc0e753c9f70cf65355e234049 13ed94f02fc2a11615e3332e1cdf50e7 GOOD
2.6.25.16 002 root root 9701b00fedc1d674db536adc5e5ddf11 9701b00fedc1d674db536adc5e5ddf11 ac004c3dff696d484c31b029d9793020 fdb0e08f0e5a2b4fe6dc711ca35f430e GOOD
2.6.25.17 002 root root 47b63e5d2f59ea4f945fc954ef4aac29 47b63e5d2f59ea4f945fc954ef4aac29 1f9c9421eb0e7513df5c0bc9802800eb 30618bff93fd4fd048e20a9a6aab8e5d GOOD
2.6.25.18 002 root root a26142b7c3b02860bc1bb2eddaf621e3 a26142b7c3b02860bc1bb2eddaf621e3 290621fad638dc3d9ba48fe6585eee27 f0e4680a17ba0071d1579b890e201951 GOOD
2.6.25.19 002 root root 78273a08ffe44e3a85a0574e7d67f367 78273a08ffe44e3a85a0574e7d67f367 05b9140207be21a9b67ff669df1c42bc 1b20d2d2a5a0f119372a166eaf816e13 GOOD
2.6.25.20 002 root root 6eea4d0acd22b88c124ce2dfe70a716a 6eea4d0acd22b88c124ce2dfe70a716a 696eefcb16debacfff616b999e7298da 0da698edccf03e2235abc2830a495114 GOOD
2.6.26 022 root root 75aa7264f67777b0adf16bb38b2b90fa 75aa7264f67777b0adf16bb38b2b90fa 5d5fe5d6203faa60fa8fbf03e8af20b5 5169d01c405bc3f866c59338e217968c GOOD
2.6.26.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3a62319934f36c477ea3d8bb053f6537 0061950ce2810d05a4d5417b782bc29d 74e664b7494f81568d655080e06af3bc
2.6.26.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 78a4296cee5ef15932e893a314982c6f 0ed153e3ece78823ccc3976e7458d6ea 82472622bd26bed0054790ec3e60ee00
2.6.26.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8d213371ed5147378f4c26923d8b6129 ed0d8efe5f6c5dad54f18b015734f767 90fe36b18dbac6e2f79374e2df60ac67
2.6.26.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7bc3eb65a67450cbc1a0fc52543d2eb1 15aca687f44a14635d9d3f18156c4bc0 ef17ac2e070cc729d7509ff24da9d081
2.6.26.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2c3d31c1e98b4a36ed84439a20837ec9 35806a7e00adf0121fca21a5c3c35143 98261b39a558cf0739703ffea7db9f43
2.6.26.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 59aa2ef47641c64191af3c2405b70f4e 752fd397d8fa65fe26a73bf0dd250bca d93b5b547a6bf0aa850a4e3231ac6339
2.6.26.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 90320b312a431786e0d2d64d09c0d5c9 79d2648d6e712495e8b3d9af42ca0a5d ada8af1e3ec15bd6e9bdbcadf23a9cc2
2.6.26.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bf0e9438e320f93d3ea687db9958a786 f6f632ab5de96f45f822b596a43e516a 05dd0d4f8f110b4219ae6ec7a36c046d
2.6.27 022 root root f9fb49f756036a34d26eee85240ff8fb f9fb49f756036a34d26eee85240ff8fb 482b04f680ce6676114ccfaaf8f66a55 b3e78977aa79d3754cb7f8143d7ddabd GOOD
2.6.27.1 002 root root b02d388a1b5179fd40139bdc6d5a2ccd b02d388a1b5179fd40139bdc6d5a2ccd 16f3702145fe1086379456c5450beeb8 76db536623e0ca28757c5464a9dc3fc2 GOOD
2.6.27.2 002 root root 104577a9cb43ee17832e6079a05bb37d 104577a9cb43ee17832e6079a05bb37d 4e3e7fcb39f06672560da7ea364787cf 2b526f5d73e66c9b9e78cd519e62fd97 GOOD
2.6.27.3 002 root root 88b3887f45666600820778d4d10d4d86 88b3887f45666600820778d4d10d4d86 45cd5c183f7e391ffc70ecffbac1c885 bbc6a0197c0aa9afd8d95b4eb03dcac2 GOOD
2.6.27.4 002 root root dbb8b8b58962acf4945a5d73810330d6 dbb8b8b58962acf4945a5d73810330d6 d81f0b3248fedbd04d64b36bd29d3b50 3880fe9f19b9a7690afd151326eb7ce5 GOOD
2.6.27.5 002 root root 99b5eb960d4709d8eab162696d7601dd 99b5eb960d4709d8eab162696d7601dd 1e08dcb0bdcafa156de5a4d4f32a43f7 99b687c0d2c64831cae00a046731ed94 GOOD
2.6.27.6 002 root root 921927e2cce7f3e59c4f76d54c77ffcb 921927e2cce7f3e59c4f76d54c77ffcb abb0e4a7d19d65516fb3955fcafd4434 e0a2ccc01319efdfd5869345099f06f4 GOOD
2.6.27.7 002 root root da79852b3b31b665ddac1eaff1712747 da79852b3b31b665ddac1eaff1712747 d5ec2c2c0ab942d4c8ba3befec5441a7 db323884c7dc46e4cd33d0d944fa59a9 GOOD
2.6.27.8 002 root root 10b609f0af0a4fcf0ed18e2d076d8310 10b609f0af0a4fcf0ed18e2d076d8310 acbf27c894734fb7e8f106dd070afd88 cbdc1b350ef79dd323b9aeda5cf7f1b6 GOOD
2.6.27.9 002 root root b62bfd7ba8a13833440abb458267c8cd b62bfd7ba8a13833440abb458267c8cd d85afbc652b42e433ba3193f0cccb46f 0ca39bec243b1d90f496da021b7487f1 GOOD
2.6.27.10 002 root root 18abcd2d7d157c1cb02bc77f9c2834e7 18abcd2d7d157c1cb02bc77f9c2834e7 d4fe287fc90837eb49e525db7208d543 ef06a3ea963f556948e77971df912303 GOOD
2.6.27.11 002 root root 38c7b9727f34961d25471cf3962079fd 38c7b9727f34961d25471cf3962079fd 1c1f634c5c391a344e1be0aed106f9e9 29bf3e01673b42f7bf993aa8295b8245 GOOD
2.6.27.12 002 root root 54f8917ddd5b8c0b89e58aa348a725f0 54f8917ddd5b8c0b89e58aa348a725f0 3840920620f7db785494457b1ce5d6b6 3a81aa35effee2656cd0340f665d4f34 GOOD
2.6.27.13 002 root root 18dfed96ccf2ca4874953d5a2618ab63 18dfed96ccf2ca4874953d5a2618ab63 587cd2abd05749c05ad56ac45cc4d119 e1035cd771ef2aed59396d8cab543a0c GOOD
2.6.27.14 002 root root b8721dbdace184d588d68dc5639feb9c b8721dbdace184d588d68dc5639feb9c 0fe6d26c7cd2a8562b5e5c8b5554556e c5daccb7e206f7f0cff21f01ec1bea81 GOOD
2.6.27.15 002 root root c7e39c082d49e20cf5da354e3e603214 c7e39c082d49e20cf5da354e3e603214 6f41b442780cb4a825fd57dd9358cbaf 0756284efb091dccd012eec61def2004 GOOD
2.6.27.16 002 root root 81462897e5ddab2c09f79f9c58c6bacf 81462897e5ddab2c09f79f9c58c6bacf 3eb3b891fb008225ed4697fe16ebebf6 f6dbb2a25ba7af6f82639dc0a08376a6 GOOD
2.6.27.17 002 root root 5a03443dcef39fc7b6afa3d7ab9e22b4 5a03443dcef39fc7b6afa3d7ab9e22b4 648643f873e6a8d197bdc1d7b2be07e1 56ceaa85d19f5f19ff7ec8139ad4ad2d GOOD
2.6.27.18 002 root root 8e272f65bf0c7dc73c57d85dc6c75b9f 8e272f65bf0c7dc73c57d85dc6c75b9f 4f8983842de76f07174eda5e72d2ee30 f1c05e5771ae556a9d6224c2e76740e2 GOOD
2.6.27.19 002 root root 61e60b5c2fe91f28da019a078be8d0a5 61e60b5c2fe91f28da019a078be8d0a5 3dea19468d572ab355fb48d4671769c5 182b23174febe7cc8106dd394f368dee GOOD
2.6.27.20 002 root root 8324c79cc242afdfe86f1e5964e49d60 8324c79cc242afdfe86f1e5964e49d60 b5ae12dc14dbaebcf29d5e08e6739a5b 58bd12ef5348e5e44b7d7b678299ff9f GOOD
2.6.27.21 002 root root 13a0e7ca645dcc462a2c0f4e265a6760 13a0e7ca645dcc462a2c0f4e265a6760 28a2d38a7f1a5adaeeecdd6551af276a 2912af7938fae1a3f2a9a6bcf8c0009f GOOD
2.6.27.22 002 root root 7f76aff66928dab42db7fd9c963b0813 7f76aff66928dab42db7fd9c963b0813 14d7dcf5533b2186064227a5580cf9c5 7ae90c041e24941add42a5f6d89a6ab3 GOOD
2.6.27.23 002 root root 399cf04ceb5f05eddea8a9782cc2ddab 399cf04ceb5f05eddea8a9782cc2ddab f4b09805a0ffaa9b006cedfb5cad85e7 42db72b93641da2fe9fb0eb2ae6388d6 GOOD
2.6.27.24 002 root root 2cb77153d209a55367edc8398f4afa88 2cb77153d209a55367edc8398f4afa88 5e151df81e74fc992af3af3d43d43970 3e272117ceb50ad8ab3686ae00afa9d8 GOOD
2.6.27.25 002 root root bb963116a132b885f4902ddc1e561920 bb963116a132b885f4902ddc1e561920 404c9a0a6c9a54223a9c2b1f66be0bae 5d6dcff157f30d742c9ee28ad4589779 GOOD
2.6.27.26 002 root root 0bf3c35f3807bdd95a3e74d691392afd 0bf3c35f3807bdd95a3e74d691392afd 15823c3469931b24c5d6ab331ac10bb2 6c246d71fa4698fb0dee0ed092f0282b GOOD
2.6.27.27 002 root root 3e4f73295dc177201ab546bcb360feae 3e4f73295dc177201ab546bcb360feae c70b796328e971e7b472320c1d66580c 69c2ec59da6fcc0d2dfb4c470a721957 GOOD
2.6.27.28 002 root root e52c78805e8f44af814f9e76613e04b2 e52c78805e8f44af814f9e76613e04b2 003652f373b29da022a3f158c5b7273c f05cd17ba8ee19924c9c473219fbaa9b GOOD
2.6.27.29 002 root root 5a7de732a819d219f51fe5b47f645555 5a7de732a819d219f51fe5b47f645555 514db1b159b00f4cd9fac94845780288 ab6991ee42603a4dbfba7956a54c89a4 GOOD
2.6.27.30 002 root root a19b497d70fe55519e1fc158ce5afe0d a19b497d70fe55519e1fc158ce5afe0d f507ffe1095e18685567868814f0b400 f925e467e1a6168ac2a4a376d76571c3 GOOD
2.6.27.31 002 root root f5bd4a54000bbc19b319cd1c084c0b1a f5bd4a54000bbc19b319cd1c084c0b1a b11e975ba28cd8004c2e8d0671f84043 b066c348e0fbfa700399d62d2fdfbf11 GOOD
2.6.27.32 002 root root 7321d15dcab7a704bf4bb78a0bc0c599 7321d15dcab7a704bf4bb78a0bc0c599 09b997cdb0732fa875f666df18471586 c9fc4f6c9cbbb335c093971ffceed656 GOOD
2.6.27.33 002 root root 55fcebf49f18a06e24468d5b4b70dfd9 55fcebf49f18a06e24468d5b4b70dfd9 87dfac18a465cad12476253f348b1024 c21c398f2f80c7856c1334e34ac438b5 GOOD
2.6.27.34 002 root root 7d8eb3d81e947465a6c0deb52839b20b 7d8eb3d81e947465a6c0deb52839b20b e30a992713b46b49d2e5b7578370ce1f 4036300a95c62d6969de674901b26145 GOOD
2.6.27.35 002 root root 1289c724be385e99e89593ea39835ad9 1289c724be385e99e89593ea39835ad9 7a8b6e8a26afc82f585c04ec8c0b8cb4 a4fa9eb5ee4876522e8015ca7da3ae40 GOOD
2.6.27.36 002 root root ee2a5457dcb337956bc03059fc92c2a1 ee2a5457dcb337956bc03059fc92c2a1 743588b4b5ece590484fc094952a88dd 409e922c6e48c5b90df14634595dce52 GOOD
2.6.27.37 002 root root e90869665b6e4860828c0f7097aaa513 e90869665b6e4860828c0f7097aaa513 8aadc962b0922dc02b4fafefc9320ccb c39b730be217a8cf1000501b5e4bdd16 GOOD
2.6.27.38 002 root root 763dbfd6558ce5dee3ae8ce720b2645c 763dbfd6558ce5dee3ae8ce720b2645c eaa5ffb8b82b6c43b936f5eef325705b 347f2262d811c06063b469fced4562a2 GOOD
2.6.27.39 002 root root dc579c8445954eb512977b28224dfef9 dc579c8445954eb512977b28224dfef9 48c2af9882f88f50ef64a21c34b62376 a1f935b170d9b63c0771a579b46c1123 GOOD
2.6.27.40 002 root root a75c56fb79c601fa6a8ee753672895ef a75c56fb79c601fa6a8ee753672895ef f140e426f5ae345b5252748852ebfdef 0192177fd18fe98d3c98268ca286f8be GOOD
2.6.27.41 002 root root 832c145c0ad862d038b41c6a09e19e6f 832c145c0ad862d038b41c6a09e19e6f 4fba3a8b572e6eb613d80760fada12fc fa7de0ac40f11864f5d13f54a18fe9ad GOOD
2.6.27.42 002 root root 5df04b71553553d1e5833c65008425d5 5df04b71553553d1e5833c65008425d5 0babc187fe3f0420d7c5d6dbc5f5ef4a a33e6b22d70dd010525fc43cdda36792 GOOD
2.6.27.43 002 root root 50b70a5f28747b070bdfd0bcc7f9529b 50b70a5f28747b070bdfd0bcc7f9529b da6c3fae5aa2d353044b9735cb914f38 c530a877d468a03a0121b164008a608b GOOD
2.6.27.44 002 root root 07f9c9509becfdf6ddef4f142a2b87fd 07f9c9509becfdf6ddef4f142a2b87fd d7fa6cba565a4c03915eb7f6ac622610 06acd9c681346774f08f52b7d4e790e2 GOOD
2.6.27.45 002 root root 5df8e25fcaaf9ec0b108c68d31c1f23a 5df8e25fcaaf9ec0b108c68d31c1f23a 0e63bce115697e4c12448c958266a6d0 7f6694628915c9974ee325c8aa867cfc GOOD
2.6.27.46 002 root root feb0c66e8af4e3c73bb7675ad99633cb feb0c66e8af4e3c73bb7675ad99633cb a37732465b3ffccc38a363d45634c098 00815f6e3b4674d799dd924ea5371bb0 GOOD
2.6.27.47 002 root root a10aedc65ec24f5b9f5e7d2534adf94e a10aedc65ec24f5b9f5e7d2534adf94e f0760a94c42906bf69497eb5d91745f6 a60434da00b67d45c10e29a7602eb069 GOOD
2.6.27.48 002 root root dab808dedf4eb7e1425cdb0b30a4c8cf dab808dedf4eb7e1425cdb0b30a4c8cf 68de870ad5458f9b17105ad1e5ef342f 635fbe6263ca78a8665ba49f6e17dc11 GOOD
2.6.27.49 002 root root d0ec0912960ab79e90d228da7fac1d67 d0ec0912960ab79e90d228da7fac1d67 9cd6bc8e911154d4cd47b0b0350bd245 389b1266667e442836373aaa3ae9a906 GOOD
2.6.27.50 002 root root ce3e327c7291fe271340eaf2904a4347 ce3e327c7291fe271340eaf2904a4347 0237b80ec327334cc76dce743db529ce c7ecbc92fe6f3c5b721c43a7084a5099 GOOD
2.6.27.51 002 root root 3256ec86d0249f6f0bf967718fd35363 3256ec86d0249f6f0bf967718fd35363 8dd26f17366188f282fbc8af0df2de29 0291c28bf56e16aea98b31705d0f0a5f GOOD
2.6.27.52 002 root root ed87ed7d7fce749a3faf845c85880ef9 ed87ed7d7fce749a3faf845c85880ef9 344edff782adf44dd23a59e4e00fe4be 4113dd848a325929b279fa4b04157753 GOOD
2.6.27.53 002 root root 108d6b3f2c723bc4360e3bbbb2474aec 108d6b3f2c723bc4360e3bbbb2474aec 74cd04293010501839f464242f9cbf20 b6e0a7f9ab38e9c108060b7e56fc65b7 GOOD
2.6.27.54 002 root root cc203656605a40fca27f90e993952788 cc203656605a40fca27f90e993952788 eb7b06fa72c986757dec15043b89a6ee 45f80fbe918028be99a7f71cc648984b GOOD
2.6.27.55 002 root root 28b6bb904578f3bbc3dafe22b0f3512a 28b6bb904578f3bbc3dafe22b0f3512a b1874eba773004b4601aebf5467c54d8 02e21eaf0531ab1feb4dad1639d54e48 GOOD
2.6.27.56 002 root root d135df3b77fe7c83ecc369139719085a d135df3b77fe7c83ecc369139719085a d3e6dc3a1fc0fc0ca613c90a257d702c bdf2d3d84789a69ce6a422c7763c393e GOOD
2.6.27.57 002 root root 8a6cc185e7c91835b12c85969a3f00f3 8a6cc185e7c91835b12c85969a3f00f3 ffe5edcaf2da6ced503f5ee8306478de 418179ad31418c1fb339ac10bccf99d4 GOOD
2.6.27.58 002 root root b9f88fc59a5b7dede53249eb1cf056d5 b9f88fc59a5b7dede53249eb1cf056d5 d4d5046ee9f0ae87886f1280b1dc6e98 3bf295c147fb24df2abc98b0a969b450 GOOD
2.6.27.59 002 root root b13ed9fb91f415f16549da6b05cf0a55 b13ed9fb91f415f16549da6b05cf0a55 a9ec0caa367887f48b6ab157da6be804 28cc04e530e71be6a37bca4c7ddd90c5 GOOD
2.6.28 022 root root afb7b848123b8f2df42cf42f0845860f afb7b848123b8f2df42cf42f0845860f 062c29b626a55f09a65532538a6184d4 d351e44709c9810b85e29b877f50968a GOOD
2.6.28.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e310b48eb15e8897db9fd276822f3501 9677bf9cb0b8da192ac010f55d71dc36 5298ae8dcbb32202a16c328a046a7df4
2.6.28.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 763d014e941bfc574de13b8f2db495dc 5db081d864a28894f44c565949b97fff 8fce853ebfe658f0833d34bb1dc14d86
2.6.28.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2d4c680841ac0c6bca914e8bb3203bd0 715c7ec7db9183d931f896785ef8aec0 4504c72a84322f02fa1917c8a82f36a5
2.6.28.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0023f9d52f13929fbc878e6c497d204b 19968a11ed6e19941fdc4cd97827b5ff 8228bb7804d6d0099eadfabf701c295b
2.6.28.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 34be72201b4e707951f0af857b737be9 0cf4c46e70e19bff4d24d02786ba89ac 677e020f785f57ac48576eacb565a489
2.6.28.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f8d096f83f2d7ff1592244e37b122b04 4862fea65983bffaa62642f20ba1321b 6bb4f553551033f29d55d78b49b31733
2.6.28.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx e77300a8e11b15c87074c54d81ae83b5 12a5c040fdce12aa5e3fd29f5e88f722 72d7d509c1f997e6d043bc9c683d89f1
2.6.28.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f35ba388bb1f6f7bd8bea72eb22b0684 9f69cba9a2740b829cb09914960a51e9 8440a90637cff154195895743ef498a1
2.6.28.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cacfadf15c10896956e3776e8f603e0e 863ac05e6a7dd0fb46a664b53306716b a4a870fdb8d0a6a7f218a6e25c9d4891
2.6.28.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4c99456b1931d4f0d7f49f7d62d18431 8513345dce011467ff6067c92634c3e9 c4efb2c494d749cb5de274f8ae41c3fa
2.6.29 022 root root f614a023dd7a9b38303a35aebedb3a4d f614a023dd7a9b38303a35aebedb3a4d fbddd9081c55e4c2f99e48d0f2a269e1 64921b5ff5cdadbccfcd3820f03be7d8 GOOD
2.6.29.1 002 root root 3378af02af06b10b3725a7f90a1e2832 3378af02af06b10b3725a7f90a1e2832 b8c75fce19ab913d567ce2ceacbd1aa7 4ada43caecb08fe2af71b416b6f586d8 GOOD
2.6.29.2 002 root root df3f8999068ca47425826f97643a9b01 df3f8999068ca47425826f97643a9b01 4a6e3bb90f5e3c67a2f2af9039185402 a6839571a9e70baf821d2fb752f9c4c6 GOOD
2.6.29.3 002 root root 0c32afeb514f2909950c10704ea1c251 0c32afeb514f2909950c10704ea1c251 9db11b204a6514d34f6cdedeaf02b513 ff37c696bf0b101620b6a8a7209c57e5 GOOD
2.6.29.4 002 root root 3510ca1d830c8b9fcef92c258d0a4762 3510ca1d830c8b9fcef92c258d0a4762 9674b69a762c397ace6fc5e7096751f5 fe2d1ec5bd0f1d9d9e660c812cac7d61 GOOD
2.6.29.5 002 root root cef8e5a3bbf183e7ad3281b1f3bfe657 cef8e5a3bbf183e7ad3281b1f3bfe657 a030d6b2c8e9e38534e9ca58f9f62f04 b0bd0fa7889c0af21eee58d096e26175 GOOD
2.6.29.6 002 root root 3d9def1cc78eac6271b54194434695e3 3d9def1cc78eac6271b54194434695e3 770efe7eb2d919eb1e794f78088b893c 7cd24826fd3c7b0f83d9f662731a7865 GOOD
2.6.30 022 root root 2bca7fef9e6aeaafcf4d34740c2a511e 2bca7fef9e6aeaafcf4d34740c2a511e 0f50954dc556d28b2b5719722f599380 7a80058a6382e5108cdb5554d1609615 GOOD
2.6.30.1 002 root root 1f57a5f8a65bd38e7b9c2f2c1ae32f66 1f57a5f8a65bd38e7b9c2f2c1ae32f66 d6eb48048ba5877d6486c70fb5accb46 7da2e2e31f1c00f2673d2dc50de76b33 GOOD
2.6.30.2 002 root root bbc68779259558afca403ca041b49073 bbc68779259558afca403ca041b49073 5294e6ebcc148e8db363cc08694b2724 890a03483dc9843100c6b51deebfc3bd GOOD
2.6.30.3 002 root root 6a5963823ecfc432f36827d5c17b9cd0 6a5963823ecfc432f36827d5c17b9cd0 9900f3ad5adeac73382300b86ef6c3d3 5499e1fd246215d65fc7068cfb040406 GOOD
2.6.30.4 002 root root 9a3533d3a716913fdf7f8b73f1beae45 9a3533d3a716913fdf7f8b73f1beae45 ad42fc4417bb0a130c769fbf0ba4221a ac05e32764368af7eff79c5e3df65efb GOOD
2.6.30.5 002 root root b446af3c919a4cf65008b61f75e88cd6 b446af3c919a4cf65008b61f75e88cd6 daea7f2a981260e82aec0fbfce466f5a be9c3a697a54ac099c910d068ff0dc03 GOOD
2.6.30.6 002 root root 4d87e17f3b3448ce7e69afc9debf0efd 4d87e17f3b3448ce7e69afc9debf0efd 59932afb4ab8ebc5525d69422988a00b 3ae3add6838da3c5a53baa87c9e32924 GOOD
2.6.30.7 002 root root e5a18192355fc18831f83ad8338378f9 e5a18192355fc18831f83ad8338378f9 f85c1f970ac430d3c239bdf7ff4c72d9 40ac5c687ffd7b4d456fa61e7b250911 GOOD
2.6.30.8 002 root root f6c70ebeaaa1e0f23cf4310bba9ac827 f6c70ebeaaa1e0f23cf4310bba9ac827 8ab4dc01676fea0e17dc30b2f94947e7 76b8397bfb477788b26c834f71e27df6 GOOD
2.6.30.9 002 root root 327a5876f9884ac4e2dd79b642790b4f 327a5876f9884ac4e2dd79b642790b4f 69e356027dc7c78190f7c70ae8b1d5d4 5a4cd5543a9d7c1a819700b21be31ef1 GOOD
2.6.30.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 135720e3d5cf72949a6e2c7b7a1661ac 9ef9dd7efee7d6831c770557222987e4 eb6be465f914275967a5602cb33662f5
2.6.31 022 root root 153f6267e44f5d32a364aa61e2b8c537 153f6267e44f5d32a364aa61e2b8c537 16c0355d3612806ef87addf7c9f8c9f9 84c077a37684e4cbfa67b18154390d8a GOOD
2.6.31.1 002 root root 0697e50b0515da0c94700a56acaf84f1 0697e50b0515da0c94700a56acaf84f1 1ce57ad412b8497d2bb87728b22d244d 8077cd7f7c1cdeb6aef3872441ae5294 GOOD
2.6.31.2 002 root root 4e5ee234f4d1ce8a2a97e81d1c3e5e3e 4e5ee234f4d1ce8a2a97e81d1c3e5e3e d7a47e2a6de48ec3831634d3868cc601 2af44f2a4c41e771894058889f976b92 GOOD
2.6.31.3 002 root root f686666a2218afd13f2c6bc794919615 f686666a2218afd13f2c6bc794919615 19ba8cfdedeb2c59e299526472a2741e 15dbe80bdc5f4135708762ff980080ea GOOD
2.6.31.4 002 root root e2e84fc3cea9293517698f2af02e3698 e2e84fc3cea9293517698f2af02e3698 1f8185cc6d3892ce3d51efb200a0c585 ae7fde9fd0ae0d8ac12a1e1536d6d3ce GOOD
2.6.31.5 002 root root a1518ae179af94eb840024655ed4471a a1518ae179af94eb840024655ed4471a cb58822f6046ae2ec13a3ee4bf13896e 926bff46d24e2f303e4ee92234e394d8 GOOD
2.6.31.6 002 root root 660348915031cc50ede9b6ae2028bf52 660348915031cc50ede9b6ae2028bf52 83323fd772d0e32e4c0c5e16542f9c6e 485472df88af84becdcf47f45de3ba46 GOOD
2.6.31.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c582645a702bc6a539c6487bd30395b0 b82342ff9af52e850ec839f1a9af5212 ae93db04f169f35c98e786f25e84c237
2.6.31.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 18c68d06d5890d977794ce6a3cc1a22d 6040125c886efca89ff76ad296834e26 660eb7bb5f3a9a161783d6fd08b734a3
2.6.31.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7470567730a8a92fa106ed9bf04d48b9 3eaee735c2638e5ca9366c156de2410b e531261b99e34208eb823be63fb0ce91
2.6.31.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bf9694c4e8cb35df6a7fa961ebdb2604 45a97e911650f9085fbb4b835c95aed0 dccdd300961d5baf3d39c904f97b5447
2.6.31.11 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 73961039212a73f69759ec5a9571c691 c43d50a49aa9ee59fc7170b7be8ea9bf 39e34c9a6439bcd4c088abe631302a99
2.6.31.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 183033ca01ac9acc29c4c5c3934d910b f307fbbb3b73905ea26e20c48d2f0f54 517be354b81b780e2f4b2ad614d030de
2.6.31.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4270ee1105fa539454d81df906ebcffb 49892e185efc74eed80ffeee88975717 a78fa43be317ee936b79df5e84f917a2
2.6.31.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 53b37dc7feb156704ba3e6ff41cac8a0 531292d59308acaa989e18bccd782ae7 3e7feb224197d8e174a90dd3759979fd
2.6.32 022 root root d1fef908e3b72c37b925e1a399d1a035 d1fef908e3b72c37b925e1a399d1a035 4b1f6f6fac43a23e783079db589fc7e2 260551284ac224c3a43c4adac7df4879 GOOD
2.6.32.1 002 root root 5be63bd57f8672db69198a8ec7a04637 5be63bd57f8672db69198a8ec7a04637 ae1ef1b076bcb75de5452723131d4570 fc95ca275124537661d64428f79bae50 GOOD
2.6.32.2 002 root root cbd1bab8027a01ec42c28278879a7209 cbd1bab8027a01ec42c28278879a7209 edab33d73bf12eb000b51e2248fe2493 9809778a867dfd3d6811a2f929256334 GOOD
2.6.32.3 002 root root 8dd90672223a82d8cbfa9bf0ecf6c70b 8dd90672223a82d8cbfa9bf0ecf6c70b cc3056d350e2f960f9d42c954f8f63de 730045c2c7f7e6618db3c4d4d7094853 GOOD
2.6.32.4 002 root root 2cf5b76b3aa71790215b45afcfa8906e 2cf5b76b3aa71790215b45afcfa8906e 2d30cf9ba08d4c04754a3457e275cb83 471e0fe07e27796f041ecb990302ccc4 GOOD
2.6.32.5 002 root root cc137ff7c3f9cd033bab9ddadfa09b9b cc137ff7c3f9cd033bab9ddadfa09b9b e2341d4f225959358e950833cf0758cc 942f676ea51c8ee53212d2f87ed60551 GOOD
2.6.32.6 002 root root d1561434aa81622f6b17b72c8e00c226 d1561434aa81622f6b17b72c8e00c226 11ddb00d7569c6b8747c6c309e8575e0 5ad2ea7b6aed2d857dd9bb5ae03588e4 GOOD
2.6.32.7 002 root root c0fcd24b3b3783afefda8f77b0c95a03 c0fcd24b3b3783afefda8f77b0c95a03 ceff62c9522950a6261120424a3ade1e d59aca06609cedabe4d6d161d9f11113 GOOD
2.6.32.8 002 root root 2e09e2ecd521b5fb43cc577e88e98356 2e09e2ecd521b5fb43cc577e88e98356 813a1d2c3709756d6b234162fd1d89c4 82023ede52f067fcc55c5e70b02e48ae GOOD
2.6.32.9 002 root root 9e1ddce5bf49fbf740fe4967990b3f83 9e1ddce5bf49fbf740fe4967990b3f83 b78dfc2f66af6c964a147f02abd5d927 0771a9c70503c92f40d815ef76eb62fe GOOD
2.6.32.10 002 root root 32aa41fbc18fbe1cf1e8535e677c13a4 32aa41fbc18fbe1cf1e8535e677c13a4 5c1140756b29e34fd7bc284a6abaff35 5d996507ad482a3a8c8e6b2d48e7994b GOOD
2.6.32.11 002 root root 212f747ca5999b395bcc03799399b8ad 212f747ca5999b395bcc03799399b8ad fddf009351f27fdef561d342ae7e7593 3709c691d909b4f8ca692edc6c726cb6 GOOD
2.6.32.12 002 root root b73836b409909ba691e442a851221bab b73836b409909ba691e442a851221bab cfb8514dc683ac7c875d64d31908e3ab bc87db696ed4be729334584493d6d98d GOOD
2.6.32.13 002 root root 1f72687582dd1bf5aa7d9a1b01ac11f5 1f72687582dd1bf5aa7d9a1b01ac11f5 ba0d81958297e448b9794b9c7d8e6853 e66b1ec7eeb1a5f5d279574c6a2f3655 GOOD
2.6.32.14 002 root root 8af1c02cefc69f902008b6d16e2a5f19 8af1c02cefc69f902008b6d16e2a5f19 2b56e9ffe03bfb6b3913bec21f58b5c1 b13dc3ce727039597163cb4bce4cbdbb GOOD
2.6.32.15 002 root root c86b467e8649d5b782e5c85d7bada2c3 c86b467e8649d5b782e5c85d7bada2c3 4c0c73dc4bac0e83981363b7da3f2124 1cbbf16e93bbe03368172872690600c0 GOOD
2.6.32.16 002 root root 34f9d86da519c3ac868bb6b9c0edf5fd 34f9d86da519c3ac868bb6b9c0edf5fd 8b42d77e1dbf1d4bf7f887643b046426 d94d91ef3be4eb76765401b4fa462759 GOOD
2.6.32.17 002 root root 41fa851916eb3e208eb2d07d9a2edc20 41fa851916eb3e208eb2d07d9a2edc20 af941edba8b0ce5e026e4af9c64ea589 33e4f0d69e5d4cb0c1bb2357b27a05be GOOD
2.6.32.18 002 root root e93ea8c463c761b6733ca9550de9d28d e93ea8c463c761b6733ca9550de9d28d 6b4e6f1a012f9bc6de10ddca007d4f5f 8c8b82d4bf607ddb233deaf7f1c44f0f GOOD
2.6.32.19 002 root root baa03d63e6eb52c870ef5f4dee6bff81 baa03d63e6eb52c870ef5f4dee6bff81 4c07d9ea18c6eb98f0be7f1b2181e155 7f32112095a164e1330c07be72966ccb GOOD
2.6.32.20 002 root root 9b4b3ccbdb161284db7c50d8fa7a9cc4 9b4b3ccbdb161284db7c50d8fa7a9cc4 fb5dbf788cd4669a481cc8913e40f22f c254831e3f59b9fef14e61871e5f4738 GOOD
2.6.32.21 002 root root 4e2d3f2ca147c1d18a0c042bb39e8296 4e2d3f2ca147c1d18a0c042bb39e8296 fbc722a582675ab1039d6f89d60682f2 e4acefa00c5b8fcc539d9cbf34d88cdb GOOD
2.6.32.22 002 root root c1bbd1b7be8f5bc5b8ec845ba4cfa6d6 c1bbd1b7be8f5bc5b8ec845ba4cfa6d6 6e9eea6ce8ad06b3d16d872dc192f111 c53844ab98703777b0546b5061606a47 GOOD
2.6.32.23 002 root root 7706a8fa891540f5eaaf0b504505473d 7706a8fa891540f5eaaf0b504505473d e5a0643a9ff87cf4c361d21c7baadf75 f9fbeb2fc55fc41e5e7df16563d33ad1 GOOD
2.6.32.24 002 root root e19d2bef8b40fe3870bb0b8e9bfa2f4b e19d2bef8b40fe3870bb0b8e9bfa2f4b e43f2b6c1f95e1963f005c422f9bb7a6 bcd2f2b3d6974a9232b9becee8196634 GOOD
2.6.32.25 002 root root 1e8ea8d88db9ea220746c317c891c6d7 1e8ea8d88db9ea220746c317c891c6d7 f4c9139704e64eb87228d3dda8df1852 0d6ad4e7e387f56c5b5831beb97c0c1f GOOD
2.6.32.26 002 root root 21db42cb4175753d6b702138b2d16035 21db42cb4175753d6b702138b2d16035 b301eade70974269918484c83469795a bdb37b8e48aaf33d9bd6e2af3ae2f1ea GOOD
2.6.32.27 002 root root f3b4b1aefc240a75b84ce8c83c1d8203 f3b4b1aefc240a75b84ce8c83c1d8203 4c7b2c1f39a23027dcd1d9ae53e98805 c8df8bed01a3b7e4ce13563e74181d71 GOOD
2.6.32.28 002 root root c63f9b5a3344f866620f6ae10be15881 c63f9b5a3344f866620f6ae10be15881 acc40b3d114c67fc28857b93fe416c4e 9ee6d4023f34eb055ec32f201b5f9206 GOOD
2.6.32.29 002 root root a6546c1fad45fa336885860d31f89b9e a6546c1fad45fa336885860d31f89b9e ed37db5e3c2865f17796a003aa5d6c70 0eea644c2cef06b4ec170228866b9685 GOOD
2.6.32.30 002 root root 8b3e0d9612b61cdbf4a9a01566010fa4 8b3e0d9612b61cdbf4a9a01566010fa4 6c43c3c5144f4b4cac0073b052f90b64 ae69df88a6c68bd0a394ad6077d5c61c GOOD
2.6.32.31 002 root root 5dcf526758804fa382f231073a442ebe 5dcf526758804fa382f231073a442ebe a1202b74ff6db879834b45d4f792e404 25c432c979f0ec3a67a35f2b8fbd0a4f GOOD
2.6.32.32 002 root root a3fd490344081ddc863c85e066c26de4 a3fd490344081ddc863c85e066c26de4 b4a0ef12f0c495d4559a0e2199c9f34b 25a3ba004aaaa409c24dfb2cc268d03e GOOD
2.6.32.33 002 root root a22b0dd689764e1aa2abcbc4f3f38899 a22b0dd689764e1aa2abcbc4f3f38899 7341b2f5672f19435434147678be1664 2b4e5ed210534d9b4f5a563089dfcc80 GOOD
2.6.32.34 002 root root 7c596527748f917b0df22321b83c9eb9 7c596527748f917b0df22321b83c9eb9 4e8a70aa35a18fda9e6ff034e15f9a7e 0617b091120c1472e313ec5ecfd8cadd GOOD
2.6.32.35 002 root root 31b9c268a72f183b37a609ce1688ed33 31b9c268a72f183b37a609ce1688ed33 19ae9d746a70788bbfe741c1dbc02329 e16032fa32779668447529e930282cce GOOD
2.6.32.36 002 root root 21d809b12592e91d100f40ee9c415e94 21d809b12592e91d100f40ee9c415e94 3020bf5a681f1b9b17cacb5a5dd54270 71cd2ab6060fb929fc0d81f4d13b88a8 GOOD
2.6.32.37 002 root root 88572d1d95f9417a93db60a954f3ce9c 88572d1d95f9417a93db60a954f3ce9c 90414a762722e5ff4ed1c0dfe64b52e9 f0a302ea6883304c3a6a492f620a14ba GOOD
2.6.32.38 002 root root 75e4d93ea9c57c28acd169902c70ffe7 75e4d93ea9c57c28acd169902c70ffe7 9a6e34ae9209568e090a64eb01b25078 7aee33b26864e31d5d0859d0ed10a88d GOOD
2.6.32.39 002 root root 6d266224d3ff0d136b336228fe108f3a 6d266224d3ff0d136b336228fe108f3a f89848dbd474e25f2b7dedd13c42a401 e0e741937640a875392b1820e945be25 GOOD
2.6.32.40 002 root root 27cd2ab5f45c83effbca8f894b9bf9a4 27cd2ab5f45c83effbca8f894b9bf9a4 5423e3dca8f18bdaf278f78df215776c 043403f6264c1ec0aea67a5f039d0a31 GOOD
2.6.32.41 002 root root 3da56d911ae16e1d9d04d27e97140094 3da56d911ae16e1d9d04d27e97140094 39efe42435365ef3a5f0e43bcab8a519 919fe13fe57f903eb03e291dcaeabf57 GOOD
2.6.32.42 002 root root 74189193fa0b44a74bfe31de2934396f 74189193fa0b44a74bfe31de2934396f 406b9bb2bde4e54ab210cd7915b627af f1bb2e5ff5ae8d552e6cedeaa70da25e GOOD
2.6.32.43 002 root root 702e1151878c159021bfed717483d078 702e1151878c159021bfed717483d078 9748e4847f9208f0a8bb9c332e1bc75f d6819da012da0d9772ac79da9dce3d63 GOOD
2.6.32.44 002 root root -----SHA256-COMPARED-OK--------- 29c4da271ccf54602641b99e744cf03b 8cd314a3449280be8537b3aaf14fb6db 38d43bb91fff88783f57ada146415029 GOOD
2.6.32.45 002 root root -----SHA256-COMPARED-OK--------- 2cc2aab8a394e0fe20fca3194718b857 d41f1c7e704cc95fdfc3374367b6fd64 0bef1e1b288adbb0e5175f9df804136c GOOD
2.6.32.46 002 root root -----SHA256-COMPARED-OK--------- c7847bdc87eb7781c7bcacae5c05c91b 73400c79feb280690c74dd0d9f4ffd6c 5f1e580ef27bb7e3a51a5e848d223e26 GOOD
2.6.33 022 root root 7fb6c834df94d78ad1dc118ba98bab21 7fb6c834df94d78ad1dc118ba98bab21 47512dfa97ba20245907feca2c507006 c3883760b18d50e8d78819c54d579b00 GOOD
2.6.33.1 002 root root c604a96b1006c24da58237b9e55195a9 c604a96b1006c24da58237b9e55195a9 7abd10bff798a6171127e69efcf36ee7 73b514ec918b88a45656be191b1ee226 GOOD
2.6.33.2 002 root root 6453571f38b4dfaa602f7585a7616c48 6453571f38b4dfaa602f7585a7616c48 f2589ee097d2c69b573babcfd2efe67f 80c5ff544b0ee4d9b5d8b8b89d4a0ef9 GOOD
2.6.33.3 002 root root a940c369b6d48fd3aea62d86d3a3b324 a940c369b6d48fd3aea62d86d3a3b324 a1809b6054650d0fe89152c0459d644c f651e9aafb2f910812257a63bcd639f2 GOOD
2.6.33.4 002 root root a21a8802c2f3a304d79a2b0a6c7d9366 a21a8802c2f3a304d79a2b0a6c7d9366 3f11fe8a42a117ea80dc26bef5174805 f75d21e5c60f18adf0e99d61c243f964 GOOD
2.6.33.5 002 root root 614d843285a93253eec2431124c5b090 614d843285a93253eec2431124c5b090 bcad38544b4ab5d4abd766112afc3575 4ca73d59b9bdb8f8c30527b17676364d GOOD
2.6.33.6 002 root root -----SHA256-COMPARED-OK--------- c0c49ff442a9a38bf19b54981c396477 9b9dd78cddf3edaae54ce9041b4d0fb5 7d8f8a4a09866a786fb59c53fba8232a GOOD
2.6.33.7 002 root root -----SHA256-COMPARED-OK--------- f954231ecad72c06ef7564d46406e44f 3e3cb86995b3c31ecd01b63c1f444886 2cea51deeaa0620a07d005ec3b148f06 GOOD
2.6.33.8 002 root root -----SHA256-COMPARED-OK--------- 495e5af33b256ff056accf8650986be3 9fe0191d3d5edf9c3fbd4fa9c39a2509 771b6a35800d64ada3956ec715ec267c GOOD
2.6.33.9 002 root root -----SHA256-COMPARED-OK--------- faab2b03eff6543c8bf63101309b61b4 2cfee0265daeb53706b7e981814af109 f518f2ef32b3d740f4ac00189d781b9a GOOD
2.6.33.10 002 root root -----SHA256-COMPARED-OK--------- d0466173fe28142b1079041d35e3d326 21aaccd06eceeb17c017124d915a62c0 1b640e4febf64e541f7f42bf4f2330ab GOOD
2.6.33.11 002 root root -----SHA256-COMPARED-OK--------- bd13cd19cf5ad42a027db60a557ac27b f02801368a879fd6edd8398dae6db526 e8db8741567e464c15ca137097181543 GOOD
2.6.33.12 002 root root -----SHA256-COMPARED-OK--------- cfb4eeb135b2f872d782b51511c039a5 6ea18c9bf4fd909272d9a60ebb1a2ddc 9aa6210598abb462454e972aa4f07165 GOOD
2.6.33.13 002 root root -----SHA256-COMPARED-OK--------- f577df3c53a265e4a76aeecbd563d332 afde0d498a65c698288422c412e32735 96b81c9dd2c0aa7a0b32433c7dcaf034 GOOD
2.6.33.14 002 root root -----SHA256-COMPARED-OK--------- 7805feff0bf8a657d16c5881459f1add 753664a8b45f032f33ef5df7366ba0f1 07e05b47d2fabbcdad7ad35e674795ad GOOD
2.6.33.15 002 root root -----SHA256-COMPARED-OK--------- a807da8ad93204739e739ddcd06afdd4 dd8dd0cbc87a255cdcb69f2d28950de5 48ba7821051fe60563f6a494eed7f403 GOOD
2.6.33.16 002 root root -----SHA256-COMPARED-OK--------- 7c7d462611cd35e979e3ff2408765bf4 78544082ee6f62171ec6f8e860cfdfe7 06e70d305aafac5789e1fd8e5077aac7 GOOD
2.6.33.17 002 root root -----SHA256-COMPARED-OK--------- 9a3f51532f5f753de84145b1bc8dde2f a9950bf9ff5cc84373be7de9bcf21727 ce484fe5a31dd95e27f7d4c6289f6695 GOOD
2.6.33.18 002 root root -----SHA256-COMPARED-OK--------- 5d5666fc2b7b070de62dc9b581ee2c14 9ec37439f478ceff34a2b13cc4cec732 38849b15dc3c28d80451f6852d657463 GOOD
2.6.33.19 002 root root -----SHA256-COMPARED-OK--------- 4f7c313f0ec36aa080bea2a29d267978 42bc20e406ee4e3a9292a9969f58b21f 49a7e37b2cfe87bf9f9df7b4efba94d0 GOOD
2.6.34 022 root root b36063fb6a50e736dc65f1798b4ec12f b36063fb6a50e736dc65f1798b4ec12f 47ed5ccd99d04352253e43d4bc84ea6a 10eebcb0178fb4540e2165bfd7efc7ad GOOD
2.6.34.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b5ab09577bac71665b0a6afc01aa8991 198c29eff8256c851e2b8e9a1369339c d31d241dc2058698a45fe41359cafb45
2.6.34.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a51d818279e0402e0f9810f1a81896a4 971c406b402d5c0a46800ce3cf644d1e bccca90a4bfd74b1335012e78d433cd5
2.6.34.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4171780e929adb9bcf845894d4b34772 eac833497feaa8c5896e3fb79dcd8ad8 8d485588afc2c47fda6da13d0392baea
2.6.34.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 13f3eb829305c9662a7c61808cd78f5e 8017efe8c7fd53ff4824b91e8740049e 2ceaa35712bfb073e31c54f3bbb75b0b
2.6.34.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx b52ed8d879f462f80b4171874e345ce2 b27b341b54e4378e7ee461a308c7402a d280b596b32f7497bbe9dd54669c99d6
2.6.34.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6ff1290538fc568f5c5dec8be92e7304 3884b783e8a596944afd912cc08a4073 032e1d886bf4affb506635be34a25b9d
2.6.34.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 20d960afa5c81924595bb631aeb25bfe cd6590845d33987e2b67c36e93254082 8964e26120e84844998a673464a980ea
2.6.34.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9fdc14cbd5272d7951536567ea4d9f28 822311a54b7008642a2f9d76063f63ba 6dedac89df1af57b08981fcc6ad387db
2.6.34.9 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f81345937f54527cdf05e6e288ca350e 3a5ad3845fb5224924b2d4bd55b0b072 94fb09b4857f9c67539782ff9cc32dd4
2.6.34.10 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a82c7a3b88e347b158251688020d5206 f60bd1faf6ccec530eb0b9a1ab55af7f d7c5dee6cf999b60b01b4ec14c54d6aa
2.6.35 022 root root 76e96f2df4eeea351787c65b3b264986 76e96f2df4eeea351787c65b3b264986 62001687bd94d1c0dd9a3654c64257d6 091abeb4684ce03d1d936851618687b6 GOOD
2.6.35.1 002 root root 208ecf7446037da8929cd89d00201eb6 208ecf7446037da8929cd89d00201eb6 a88f1bcb6d331155cc0cdba9a3cdb508 27b266dda534761fb027a6c47605b7e3 GOOD
2.6.35.2 002 root root f05f0e9210ed73e1f2471d3c5053a959 f05f0e9210ed73e1f2471d3c5053a959 1f2da16491fe2c3f68a48170749c1731 0da1c090199663c180d8a60bf49de36e GOOD
2.6.35.3 002 root root 1cbcb42ebbfd2644ec671ec76c30ade7 1cbcb42ebbfd2644ec671ec76c30ade7 887800197a74a160de27f53cd3a75c79 5ebff49fd65a7bad234ce103b0b3ede0 GOOD
2.6.35.4 002 root root 19a1f86ee7412f80f7ce169a5e126923 19a1f86ee7412f80f7ce169a5e126923 6a2d7e0fa99bea0a3c209c98a3745466 0bb2cd59c13d7412f813c8fbc0769eec GOOD
2.6.35.5 002 root root 2e5f5a226293a3c56dad081887ff809c 2e5f5a226293a3c56dad081887ff809c c86fcedd98ab0d64fe981575bb06a5c8 ebf9f05360acc0d2405284f0c24fed7e GOOD
2.6.35.6 002 root root 2f7443cf4efbe36239bcf14488c5a883 2f7443cf4efbe36239bcf14488c5a883 55b944af9b96651cf8a34e4a7fa38a1b 26ff1af2a0a398d3b6ef60bb8ce311d4 GOOD
2.6.35.7 002 root root bb61b92a0570d10eec4dea37aa84c605 bb61b92a0570d10eec4dea37aa84c605 e09a37dcfdbf256ef20039d0d8fb8058 f741879bcd3a5366a1bbe0ad5cdb7935 GOOD
2.6.35.8 002 root root 7038815cdb8de9591da6509ae6925714 7038815cdb8de9591da6509ae6925714 51981683457e3cf19b137a5a0df8d0bb 10ccef307e81fb405b01457f312a8c66 GOOD
2.6.35.9 002 root root 83d50d1b4c46dadab70da7a2172d0819 83d50d1b4c46dadab70da7a2172d0819 85967dc97fb1d5ee50eb53375a652d93 18d339e9229560e73c4249dffdc3fd90 GOOD
2.6.35.10 002 root root 122a6b0854a9b461dd1271afa6c29826 122a6b0854a9b461dd1271afa6c29826 5f8d0539af9b94a1b5ffef1f3358f73a 8d3732acee1b7ae9c26c70be15b8c8cc GOOD
2.6.35.11 002 root root ff345053ea0724127f36a7305afa4340 ff345053ea0724127f36a7305afa4340 f3b6db4ca6f1b9856a20f2c160d527e0 4c9ee33801f5ad0f4d5e615fac66d535 GOOD
2.6.35.12 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6685f3b35b5df4f19290b70c787c4650 7eff266164b794ddaf07d16a5d650259 cc9165deeb48ceeaab14ff5eb2f55cb6
2.6.35.13 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3cbd9006a7cde4efc2ef669aced7e5fc 2c02fb9f091673aba3e3203ca8a55168 ff6c850159de960f26e010fba08f4d59
2.6.35.14 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx fc558717fc5ce042f83f6444285c33c6 dfe2630473a7edea339a736ffac67eec 5a0af287a9cc5998321d67cbe112d1f8
2.6.36 022 root root 2f4d3b5d66aa1c1465e0c05e3c5f36ac 2f4d3b5d66aa1c1465e0c05e3c5f36ac 9083f8da705b0102bcb8999079437132 61f3739a73afb6914cb007f37fb09b62 GOOD
2.6.36.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 44944e1bf4bbe6be6c9b19caabd2e46a ef410ffece297e8b827fec99cb32b32f 0f1398ad1fcfc14f2420010bc8a03ca9
2.6.36.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8b6557c4f0cef60b1c0cfd389ac76c81 79383b9cf01cd4b9255b8b9e3a80b0c5 d465f8ba05bf1b7530c596f1cca658e7
2.6.36.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ac4a519bd303d1552bdf2ef28cea9400 da2224c44d3316fea2316a0ff368b4f1 e23fd2fa5268300038e179919c590f69
2.6.36.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx eb84076b4f2ffbe6ec397db09c4b76c0 77b981f8319d238856e6e98b3aac0e50 c05dd941d0e249695e9f72568888e1bf
2.6.37 022 root root 943a4f25288d86b1dbf7808eb539bd42 943a4f25288d86b1dbf7808eb539bd42 c877f8429254e4a4981028b90ea9bb10 c8ee37b4fdccdb651e0603d35350b434 GOOD
2.6.37.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a358b14b41133571d8d006c1799c748c 588bef60117c34162b1835f9b0ec5251 07d3b1868a67c1a7ddcf1d54444cb5d1
2.6.37.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 42865250767ded55861ae0cc569f4cdf 136adc84115d9529a11c875cc861cf8d 89f681bc7c917a84aa7470da6eed5101
2.6.37.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 4cefa352f70a1f5b61f91a7ffcfe4f5b c498fd2c9451849117c1ed29a31466c6 b32fc95037e4e114fcfb33075bb30f46
2.6.37.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1faea970049f982abd1f735c0eaf5200 639108993d53de32ae3fffb5eb2820ed 1d2dc321017a8dde09b779b4d8233273
2.6.37.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 918d912d411ecafe07c4c536a192a860 9c01abb4f975f9cf3b5e3dffb62292ae 8f84193d5a08b909aaad2cf30329df1a
2.6.37.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 8c5acdd2de588e03cf788f51ba49fd52 77016b346480466d649ec9d719d8df0a 05970afdce8ec4323a10dcd42bc4fb0c
2.6.38 022 root root 0e705fd53756f7bddcf6e4bb3f18458b 0e705fd53756f7bddcf6e4bb3f18458b cf0b587742611328f095da4b329e9fc7 7d471477bfa67546f902da62227fa976 GOOD
2.6.38.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7e61835baf0e180582e7899a53333d36 e7ef42ccbcb0fd716ef25ba1970ff64e 7716316e5fa36e570df2d79dc6067591
2.6.38.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 28b115c1e5ef3311d83449ca55eb1e93 7b45f4d238bf736f8dd4bac293d40d56 5e9d0edae15053ea9acd932e6d162d03
2.6.38.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7241f0ed5fdb946958ae07839dc37fc4 6d2ace2e134dbed592dee16320bd41b2 d3071407a33a7bd2ffb47181f200f22c
2.6.38.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7e79df0e18344fb38a5222df07124ba2 da2cef8f5c99a664e8b3b86674c49c05 bd11be3155b24415dc4d521ca26ba9e2
2.6.38.5 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c334701518dee7a785f24d10b684287e d59b33f52c32e891690a5ec0934b9c88 e81a999e1b1e08bd885bccf0d37cb6df
2.6.38.6 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx f78b06daf92715dba4f5524eda2db4c2 9ba1b51b427c917f9dde69a6b1b02bd0 e896a3bb3185b8a8af8e2f010f63c02e
2.6.38.7 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx d8ae75de84c9c8a80b3ae3628550dbe1 f1ae7efecc2742a33141fa64b9370135 fd4c33a1a7462fd076c36464d24a2d7e
2.6.38.8 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9f98099e7e89e6eacfefcde48c72c459 f779b3991fcf0e4573a5d5167a60a26b d27b85795c6bc56b5a38d7d31bf1d724
2.6.39 022 root root 833d224ee42ddc1e7c2d256368b5d7b3 833d224ee42ddc1e7c2d256368b5d7b3 d3b7d50f09c2b396edd6dd1fe8561a62 1aab7a741abe08d42e8eccf20de61e05 GOOD
2.6.39.1 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 3ec312d569811554efce499b8f5f655d 018a6ed132dd44531d11c5d56f4b528c 983834b0138e102a3fb0098367c17150
2.6.39.2 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6d5d0821f9febfcba8ce652872240b80 e5010f5da6ba96f1b31f658060439348 51be93d92028658ec93f68b79a378b17
2.6.39.3 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1b9fdd3b3ce19eec99e5c22d54c466f9 650de652a1f78c60e140f1b3be47f5e9 5afede829846587e798f2631c2ece84f
2.6.39.4 002 root root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 829d4bd2e2d2f91b8ae36f52b6f38836 1b834c566316219312e46770021e9f4a a17c748c2070168f1e784e9605ca043d

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Sunday, October 02, 2011, H. Peter Anvin wrote:
> On 10/01/2011 06:04 PM, Rafael J. Wysocki wrote:
> > 
> > OK, I'm taking this as "5 years is fine by us". :-)
> > 
> > And the recommended procedure for rotating keys seems to be (1) generate
> > a new key and (2) make as many people as you can sign it before the old
> > one expires, right?
> > 
> 
> (3) revoke the old key with a status code of "no longer in use", or just
> let it expire.
> 
> >> Some people have decided to opt for an unlimited key, but that
> >> *requires* that you have a way to revoke the old key, which is why we
> >> are considering a key revocation escrow service.
> > 
> > That service will be necessary anyway in case some keys are lost or
> > compromised.
> > 
> > I wonder what the procedure of restoring kernel.org access in case one
> > has lost keys is supposed to be?
> 
> Get a new key and get it re-signed.

Hmm.  That doesn't seem very practical if someone doesn't live close
to any other core kernel developers.

What number of signatures on the key will be regarded as sufficient?

> We can work out specific details at KS.

Well, the KS is going to be busy time this year I suppose. :-)

What about people who haven't been invited to the KS?

Rafael

Re: kernel.org status: hints on how to check your machine for intrusion

[Andy]

On Sat, Oct 01, 2011 at 09:39:48PM -0700, Greg KH wrote:
> I've did this a while ago when we were working on verifying the
> tarballs, here's what I got, one column is with the umask unset, and the
> other set to 022, both of them being the sha256sum output.

Thank you very much for posting that information.

> If this isn't sufficient, just give me a script I can run and I'll be
> glad to provide the numbers.

Many of us would benefit from having signatures for some of the recent
kernels missing for your list as well as Willy's. For example, a few
systems of mine run 2.6.39.4 due to sleep-related issues with 3.0.x+ and
those hardware platforms.

It would be great to have fingerprints for:

2.6.35.1 - 2.6.35.9 (2.6.35.14?)
2.6.36.1 - 2.6.36.4
2.6.37.1 - 2.6.37.6
2.6.38.1 - 2.6.38.8
2.6.39.1 - 2.6.39.4

Here is a script (based on Willy's) to use inside the git dirs:

for mask in 002 022
do
  git config tar.umask $mask
  echo "umask set to: $mask"
  for tag in $(git tag | grep "^v[23]" | egrep -v 'pre|rc|tree')
  do
    echo -ne "${tag#v}\t"
    git archive --format tar --prefix linux-${tag#v}/ $tag | sha256sum
  done
  echo
done  

Many thanks,

~ Andy

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 04:54 AM, Rafael J. Wysocki wrote:
> On Sunday, October 02, 2011, H. Peter Anvin wrote:
> 
> Hmm.  That doesn't seem very practical if someone doesn't live close
> to any other core kernel developers.
> 

You probably know enough people (including myself) that would be willing
to sign your key over the phone.  That's part of giving yourself
sufficient time.

> What number of signatures on the key will be regarded as sufficient?
> 
>> We can work out specific details at KS.
> 
> Well, the KS is going to be busy time this year I suppose. :-)
> What about people who haven't been invited to the KS?

Well, KS is still a place where we can discuss these kinds of policies;
we can't be a perfect democracy and in fact have never even attempted to.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Sunday, October 02, 2011, H. Peter Anvin wrote:
> On 10/02/2011 04:54 AM, Rafael J. Wysocki wrote:
> > On Sunday, October 02, 2011, H. Peter Anvin wrote:
> > 
> > Hmm.  That doesn't seem very practical if someone doesn't live close
> > to any other core kernel developers.
> > 
> 
> You probably know enough people (including myself) that would be willing
> to sign your key over the phone.  That's part of giving yourself
> sufficient time.

Well, then I propose that people create two new key pairs instead of
just one and take both of them to the KS for signing.  Afterwards, one
of them will be used for development and the other one's private key
will be kept in a safe place (without any online access), so it can be
used readily if the first pair is lost or compromised somehow.

Perhaps the second pair should have a longer life time.

> > What number of signatures on the key will be regarded as sufficient?
> > 
> >> We can work out specific details at KS.
> > 
> > Well, the KS is going to be busy time this year I suppose. :-)
> > What about people who haven't been invited to the KS?
> 
> Well, KS is still a place where we can discuss these kinds of policies;
> we can't be a perfect democracy and in fact have never even attempted to.

That doesn't seem to address my question directly.  Never mind. :-)

FYI, I am going to keep my current tree at github up to date even after
kernel.org has become operational again.  If every tree Linus pulls from
is hosted in two different locations, so that they can be used for double
checking the tree's integrity, that will improve the security of data
we want to protect much more than making access to kernel.org alone so
much more difficult.

Thanks,
Rafael

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 11:14 AM, Rafael J. Wysocki wrote:
>>
>> You probably know enough people (including myself) that would be willing
>> to sign your key over the phone.  That's part of giving yourself
>> sufficient time.
> 
> Well, then I propose that people create two new key pairs instead of
> just one and take both of them to the KS for signing.  Afterwards, one
> of them will be used for development and the other one's private key
> will be kept in a safe place (without any online access), so it can be
> used readily if the first pair is lost or compromised somehow.
> 
> Perhaps the second pair should have a longer life time.
> 

Yes, this is actually a very good practice (the long-lived key should be
a sign-only key, for what it's worth.)  I didn't propose it because I
thought it would be too much work.

What do people think?  It might be more important for people who are
physically isolated.

>>> What number of signatures on the key will be regarded as sufficient?

FWIW, the stock PGP web of trust rules require 3 signatures.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Henrique de Moraes Holschuh]

On Sat, 01 Oct 2011, H. Peter Anvin wrote:
> On 10/01/2011 02:33 PM, Rafael J. Wysocki wrote:
> > 
> > OK, how long should the new key be valid?
> > 
> 
> That is a good question.  At the very least you want it to be valid for
> long enough that you will be able to get enough signatures on a new key
> *before* your old key expires.  As such I would recommend 3-5 years
> depending on how much you trust yourself to keep the key secure.
> 
> Some people have decided to opt for an unlimited key, but that
> *requires* that you have a way to revoke the old key, which is why we
> are considering a key revocation escrow service.

You can update the key expirity date at any time[1].  However, such
updates can still leave you with a lot of expired signatures, it all
depends on how the signers will set the expirity date of their
signatures when they sign your key...

This happened to my 0x1cdb0fe3 key.  It is still part of the strong set,
but it used to have much better connectivity.  It was necessary to
extend its service life, and about 3/4 of the signatures in it had
expire dates in sync with its original validity, and have now expired.

As for the key revocation escrow service, it should be kept offline and
very well protected.  If someone revokes all those keys at once, it can
cause a large service disruption at the very least.

It is also good to keep in mind that any sane security model extends the
loss of trust on a key to all signatures it has ever made and will ever
make, unless you have extra information (such as timestamp signatures
made by a still-trusted key).

On a somewhat related note, gpg supports subkeys.  When using subkeys,
you will only need the main key to sign other keys.  That means you can
have a large validity on a strong key (say: 10yr for RSA/4096) and keep
it always offline (in encrypted media, of course), and have subkeys on a
simple token or encrypted removable media for day-to-day use.

subkeys can be made to expire a lot more often (say, 1yr or 2yr
validity) without any major disadvantages, you just upload a new subkey
to the keyservers a few months before the current ones will expire.  You
can also revoke subkeys without any detrimental effects to the main key
and to your connectivity to the web of trust.

[1] that doesn't mean it will be easy to get people to accept such an
update after the key expired.  I don't think the keysevers will allow an
expired key to be "unexpired", for example.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: kernel.org status: establishing a PGP web of trust

[Henrique de Moraes Holschuh]

On Sun, 02 Oct 2011, Rafael J. Wysocki wrote:
> Well, then I propose that people create two new key pairs instead of
> just one and take both of them to the KS for signing.  Afterwards, one
> of them will be used for development and the other one's private key
> will be kept in a safe place (without any online access), so it can be
> used readily if the first pair is lost or compromised somehow.
> 
> Perhaps the second pair should have a longer life time.

Maybe subkeys would be enough/better?

http://wiki.debian.org/subkeys

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: kernel.org status: hints on how to check your machine for intrusion

[Willy Tarreau]

On Sun, Oct 02, 2011 at 07:03:52AM -0500, Andy wrote:
> Many of us would benefit from having signatures for some of the recent
> kernels missing for your list as well as Willy's. For example, a few
> systems of mine run 2.6.39.4 due to sleep-related issues with 3.0.x+ and
> those hardware platforms.
> 
> It would be great to have fingerprints for:
> 
> 2.6.35.1 - 2.6.35.9 (2.6.35.14?)

2.6.35.1...11 were covered by my last mail. The signatures are
md5 but that should be enough for checking.

> 2.6.36.1 - 2.6.36.4
> 2.6.37.1 - 2.6.37.6
> 2.6.38.1 - 2.6.38.8
> 2.6.39.1 - 2.6.39.4

I did not have these tags.

Regards,
Willy

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 11:14 AM, Rafael J. Wysocki wrote:
>>
>> Well, KS is still a place where we can discuss these kinds of policies;
>> we can't be a perfect democracy and in fact have never even attempted to.
> 
> That doesn't seem to address my question directly.  Never mind. :-)
> 

Sorry, I don't think I understood the question then.

If this is about "how do we bring non-KS developers into the web of
trust" it pretty much comes down to the more people we have that can
sign keys the more complete the web will be, and the easier it will be
for developers to get their keys signed.

Makes sense?

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Randy Dunlap]

On 10/02/11 04:54, Rafael J. Wysocki wrote:
> On Sunday, October 02, 2011, H. Peter Anvin wrote:
>> On 10/01/2011 06:04 PM, Rafael J. Wysocki wrote:
>>>
>>> OK, I'm taking this as "5 years is fine by us". :-)
>>>
>>> And the recommended procedure for rotating keys seems to be (1) generate
>>> a new key and (2) make as many people as you can sign it before the old
>>> one expires, right?
>>>
>>
>> (3) revoke the old key with a status code of "no longer in use", or just
>> let it expire.
>>
>>>> Some people have decided to opt for an unlimited key, but that
>>>> *requires* that you have a way to revoke the old key, which is why we
>>>> are considering a key revocation escrow service.
>>>
>>> That service will be necessary anyway in case some keys are lost or
>>> compromised.
>>>
>>> I wonder what the procedure of restoring kernel.org access in case one
>>> has lost keys is supposed to be?
>>
>> Get a new key and get it re-signed.
> 
> Hmm.  That doesn't seem very practical if someone doesn't live close
> to any other core kernel developers.
> 
> What number of signatures on the key will be regarded as sufficient?
> 
>> We can work out specific details at KS.
> 
> Well, the KS is going to be busy time this year I suppose. :-)
> 
> What about people who haven't been invited to the KS?

They (we) should start building a web of trust with local key signings.
I'm already working on that in Portland, Oregon.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: kernel.org status: establishing a PGP web of trust

[Willy Tarreau]

On Sun, Oct 02, 2011 at 11:19:24AM -0700, H. Peter Anvin wrote:
> On 10/02/2011 11:14 AM, Rafael J. Wysocki wrote:
> >>
> >> You probably know enough people (including myself) that would be willing
> >> to sign your key over the phone.  That's part of giving yourself
> >> sufficient time.
> > 
> > Well, then I propose that people create two new key pairs instead of
> > just one and take both of them to the KS for signing.  Afterwards, one
> > of them will be used for development and the other one's private key
> > will be kept in a safe place (without any online access), so it can be
> > used readily if the first pair is lost or compromised somehow.
> > 
> > Perhaps the second pair should have a longer life time.
> > 
> 
> Yes, this is actually a very good practice (the long-lived key should be
> a sign-only key, for what it's worth.)  I didn't propose it because I
> thought it would be too much work.
> 
> What do people think?  It might be more important for people who are
> physically isolated.

I'm not opposed to generate a second key, but I don't really understand
how it solves the isolation issue. I'm not used to key signing parties
and am presently in the situation where I don't know whom to ping to
sign my key. The only thing I could do was to sign it with my old key
as you suggested in the initial mail on the subject :-/

So if at least generating a second key can save that hassle for next
time, I'm all in favor of making it, it just takes a few seconds.

Best regards,
Willy

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 11:39 AM, Willy Tarreau wrote:
> 
> I'm not opposed to generate a second key, but I don't really understand
> how it solves the isolation issue. I'm not used to key signing parties
> and am presently in the situation where I don't know whom to ping to
> sign my key. The only thing I could do was to sign it with my old key
> as you suggested in the initial mail on the subject :-/
> 
> So if at least generating a second key can save that hassle for next
> time, I'm all in favor of making it, it just takes a few seconds.
> 

The idea is that you have a key that you keep *extremely* secure.  When
you go to key signing parties you only bring the public key (for
verifying the fingerprint) but you don't sign keys until you're at your
secure host, for example.

That is the key you will use to establish yourself in the web of trust.
 The key you will actually *use* is a child key signed with that key,
and perhaps a handful of others.

That way, if your everyday key is compromised, you can still use your
secure key to sign the everyday key.  This alone will get you "marginal"
trust in the PGP web, which is good enough to get you new credentials.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Willy Tarreau]

On Sun, Oct 02, 2011 at 12:02:33PM -0700, H. Peter Anvin wrote:
> On 10/02/2011 11:39 AM, Willy Tarreau wrote:
> > 
> > I'm not opposed to generate a second key, but I don't really understand
> > how it solves the isolation issue. I'm not used to key signing parties
> > and am presently in the situation where I don't know whom to ping to
> > sign my key. The only thing I could do was to sign it with my old key
> > as you suggested in the initial mail on the subject :-/
> > 
> > So if at least generating a second key can save that hassle for next
> > time, I'm all in favor of making it, it just takes a few seconds.
> > 
> 
> The idea is that you have a key that you keep *extremely* secure.  When
> you go to key signing parties you only bring the public key (for
> verifying the fingerprint) but you don't sign keys until you're at your
> secure host, for example.
> 
> That is the key you will use to establish yourself in the web of trust.
>  The key you will actually *use* is a child key signed with that key,
> and perhaps a handful of others.
> 
> That way, if your everyday key is compromised, you can still use your
> secure key to sign the everyday key.  This alone will get you "marginal"
> trust in the PGP web, which is good enough to get you new credentials.

OK that makes sense. Thanks for the explanation.

Willy

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Sunday, October 02, 2011, H. Peter Anvin wrote:
> On 10/02/2011 11:39 AM, Willy Tarreau wrote:
> > 
> > I'm not opposed to generate a second key, but I don't really understand
> > how it solves the isolation issue. I'm not used to key signing parties
> > and am presently in the situation where I don't know whom to ping to
> > sign my key. The only thing I could do was to sign it with my old key
> > as you suggested in the initial mail on the subject :-/
> > 
> > So if at least generating a second key can save that hassle for next
> > time, I'm all in favor of making it, it just takes a few seconds.
> > 
> 
> The idea is that you have a key that you keep *extremely* secure.  When
> you go to key signing parties you only bring the public key (for
> verifying the fingerprint) but you don't sign keys until you're at your
> secure host, for example.
>
> That is the key you will use to establish yourself in the web of trust.
>  The key you will actually *use* is a child key signed with that key,
> and perhaps a handful of others.

OK, call the "extremely secure" key pair a "master".  So, in practice I'll only
take the master and child public keys (the child key signed with the master)
with me to the KS.  At the KS I'll collect the IDs and fingerprints of
people's keys to sign and I'll sign them, with the master key, when I'm back
at my secure host.  I also give my public keys (both master and child) to
people for signing.

Is this what you mean?

Rafael

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Sunday, October 02, 2011, H. Peter Anvin wrote:
> On 10/02/2011 11:14 AM, Rafael J. Wysocki wrote:
> >>
> >> Well, KS is still a place where we can discuss these kinds of policies;
> >> we can't be a perfect democracy and in fact have never even attempted to.
> > 
> > That doesn't seem to address my question directly.  Never mind. :-)
> > 
> 
> Sorry, I don't think I understood the question then.
> 
> If this is about "how do we bring non-KS developers into the web of
> trust" it pretty much comes down to the more people we have that can
> sign keys the more complete the web will be, and the easier it will be
> for developers to get their keys signed.
> 
> Makes sense?

Yes, it does, except that it will leave the people not at the KS and
unable to create their own small webs of trust somewhat in the dust.

Thanks,
Rafael

Re: kernel.org status: establishing a PGP web of trust

[Henrique de Moraes Holschuh]

On Sun, 02 Oct 2011, Rafael J. Wysocki wrote:
> Yes, it does, except that it will leave the people not at the KS and
> unable to create their own small webs of trust somewhat in the dust.

Look outside LKML.  For example, try to locate a Debian developer near
you, it shouldn't be too dificult[0] and you are almost guaranteed to
join the web-of-trust strong set[1] if you get your key cross-signed
with a Debian Developer[2].

[0] http://www.debian.org/devel/developers.loc

[1] The strong set is the largest set of keys such that for any two keys
in the set, there is a path from one to the other, refer to:
http://pgp.cs.uu.nl/plot/

[2] Based on the report from 2/17/08, an examination of 201,989 publicly
available keys found a strong set of 110,957 keys (about 54% of the
sample). In this strong set, the average MSD was 6.3449. The most
connected key belongs to Peter Palfrader and has an MSD of 3.5588. One
interesting phenomenon is that all of the top (most connected) 25 keys
and all but 12 of the top 50 keys belong to people involved with the
Debian project. The Debian project relies very heavily on GPG for
authentication and demands that members be in the web of trust before
they can join.  Quoted from:
http://expertvoices.nsdl.org/cornell-info204/2008/02/28/pgpgpg-the-web-of-trust-and-the-strong-set/

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On Sun, 02 Oct 2011 11:36:05 PDT, Randy Dunlap said:

> They (we) should start building a web of trust with local key signings.
> I'm already working on that in Portland, Oregon.

Don't forget to include people who may not be attending KS, but are able to
contribute signatures.  If you're in this part of southwest Virginia, I can
probably get a PGP key signed by 3 different people who have totally disjoint
paths to the main part of the well-connected set.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Guenter Roeck]

On Sun, Oct 02, 2011 at 02:36:05PM -0400, Randy Dunlap wrote:
> On 10/02/11 04:54, Rafael J. Wysocki wrote:
> > On Sunday, October 02, 2011, H. Peter Anvin wrote:
> >> On 10/01/2011 06:04 PM, Rafael J. Wysocki wrote:
> >>>
> >>> OK, I'm taking this as "5 years is fine by us". :-)
> >>>
> >>> And the recommended procedure for rotating keys seems to be (1) generate
> >>> a new key and (2) make as many people as you can sign it before the old
> >>> one expires, right?
> >>>
> >>
> >> (3) revoke the old key with a status code of "no longer in use", or just
> >> let it expire.
> >>
> >>>> Some people have decided to opt for an unlimited key, but that
> >>>> *requires* that you have a way to revoke the old key, which is why we
> >>>> are considering a key revocation escrow service.
> >>>
> >>> That service will be necessary anyway in case some keys are lost or
> >>> compromised.
> >>>
> >>> I wonder what the procedure of restoring kernel.org access in case one
> >>> has lost keys is supposed to be?
> >>
> >> Get a new key and get it re-signed.
> > 
> > Hmm.  That doesn't seem very practical if someone doesn't live close
> > to any other core kernel developers.
> > 
> > What number of signatures on the key will be regarded as sufficient?
> > 
> >> We can work out specific details at KS.
> > 
> > Well, the KS is going to be busy time this year I suppose. :-)
> > 
> > What about people who haven't been invited to the KS?
> 
> They (we) should start building a web of trust with local key signings.
> I'm already working on that in Portland, Oregon.
> 
Anyone in Silicon Valley looking for key signings, please get in touch.

Thanks,
Guenter

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 03:54 PM, Guenter Roeck wrote:
>>
> Anyone in Silicon Valley looking for key signings, please get in touch.
> 

I would be happy to be there, and I know Olof Johansson has been talking
about one.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Nobuhiro Iwamatsu]

Hi,

2011/10/1 Greg KH <greg@kroah.com>:
> On Fri, Sep 30, 2011 at 04:50:37PM -0700, H. Peter Anvin wrote:
>> 2. Create a new PGP/GPG key, and also generate a key revocation
>>    certificate (but don't import it anywhere -- save it for the
>>    future) for your new key.  In the near future we are considering
>>    setting up an escrow service for key revocation certificates.
>>
>>    I recommend using a 4096-bit RSA key.  Given how fast computers are
>>    these days, there is no reason to use a shorter key.  DSA keys
>>    should be considered obsolete; substantial weaknesses have been
>>    found in DSA.
>>
>>    $ gpg --gen-key
>>    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
>
> I would recommend a physical access device for your new gpg key that you
> create.  I've heard good things about this USB device:
>        http://www.crypto-stick.org/
> and am trying to have a bunch of them at the Kernel Summit this year to
> hand out to people if they want one.
>
> There are also lots of other smart-card form-factor devices that can be
> used to store GPG keys.  Some places to purchase these can be found at
> links from the above site.

Maybe you know , there are the following projects, too.
 http://www.fsij.org/gnuk/

Nobuhiro
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Mon, Oct 03, 2011 at 08:02:39AM +0900, Nobuhiro Iwamatsu wrote:
> Hi,
> 
> 2011/10/1 Greg KH <greg@kroah.com>:
> > On Fri, Sep 30, 2011 at 04:50:37PM -0700, H. Peter Anvin wrote:
> >> 2. Create a new PGP/GPG key, and also generate a key revocation
> >>    certificate (but don't import it anywhere -- save it for the
> >>    future) for your new key.  In the near future we are considering
> >>    setting up an escrow service for key revocation certificates.
> >>
> >>    I recommend using a 4096-bit RSA key.  Given how fast computers are
> >>    these days, there is no reason to use a shorter key.  DSA keys
> >>    should be considered obsolete; substantial weaknesses have been
> >>    found in DSA.
> >>
> >>    $ gpg --gen-key
> >>    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
> >
> > I would recommend a physical access device for your new gpg key that you
> > create.  I've heard good things about this USB device:
> >        http://www.crypto-stick.org/
> > and am trying to have a bunch of them at the Kernel Summit this year to
> > hand out to people if they want one.
> >
> > There are also lots of other smart-card form-factor devices that can be
> > used to store GPG keys.  Some places to purchase these can be found at
> > links from the above site.
> 
> Maybe you know , there are the following projects, too.
>  http://www.fsij.org/gnuk/

Yes, I think I saw the presentation about this at the last LinuxCon
Tokyo (or was it the year before?)

It looks like a great project, but sometimes you want something already
built as you have enough hobbies as it is :)

thanks,

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[Josh Boyer]

On Sun, Oct 2, 2011 at 6:46 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Sun, 02 Oct 2011 11:36:05 PDT, Randy Dunlap said:
>
>> They (we) should start building a web of trust with local key signings.
>> I'm already working on that in Portland, Oregon.
>
> Don't forget to include people who may not be attending KS, but are able to
> contribute signatures.  If you're in this part of southwest Virginia, I can
> probably get a PGP key signed by 3 different people who have totally disjoint
> paths to the main part of the well-connected set.

I'll be around VT in January for FUDCon.  Perhaps we can schedule a keysigning.

In the meantime, if anyone happens to be in the western Michigan area,
let me know.  (Ha.)

josh

Re: kernel.org status: establishing a PGP web of trust

[Olof Johansson]

On Sun, Oct 2, 2011 at 3:58 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/02/2011 03:54 PM, Guenter Roeck wrote:
>>>
>> Anyone in Silicon Valley looking for key signings, please get in touch.
>>
>
> I would be happy to be there, and I know Olof Johansson has been talking
> about one.


Yeah, I don't think there's enough interest(?) to justify a full-blown
key signing party, but meeting up at a coffee shop or something sounds
like a good idea.


-Olof

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 04:23 PM, Olof Johansson wrote:
> On Sun, Oct 2, 2011 at 3:58 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 10/02/2011 03:54 PM, Guenter Roeck wrote:
>>>>
>>> Anyone in Silicon Valley looking for key signings, please get in touch.
>>>
>>
>> I would be happy to be there, and I know Olof Johansson has been talking
>> about one.
> 
> 
> Yeah, I don't think there's enough interest(?) to justify a full-blown
> key signing party, but meeting up at a coffee shop or something sounds
> like a good idea.
> 

FWIW, Tuesday evening works really well for me.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 03:46 PM, Valdis.Kletnieks@vt.edu wrote:
> 
> Don't forget to include people who may not be attending KS, but are able to
> contribute signatures.  If you're in this part of southwest Virginia, I can
> probably get a PGP key signed by 3 different people who have totally disjoint
> paths to the main part of the well-connected set.
> 

Yes, if anything it is more important to catch non-KS people.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: kernel.org status: establishing a PGP web of trust

[Lee Mathers]

How can us non kernel quality developers assist in making this a
reality.   I have extensive pki experience and while my certifications
are stale I still consider myself an expert in internet privacy and
security. Which are !=
I have been waiting for a long time for a series of incidents like
this to occur to linux what surprises me is the magnitude of the
impact to the community.  However to wear out an expression further
what ever does not kill you makes you stronger. I Apologize for the
for formating using gmail from a blackberry.  Which just had it's
security cracked if it makes you feel better.  But in reality this is
such has a very low impact on user security it's not like
apt-get/aptitude, yum or rpm/update are pulling the latest stuff from
kernel.org.  The impact here is felt most by the developers of the
kernel it self.  I don't know about you but I don't download new src
often I just continually apply vetted patches to both my applications
and often the kernel it self.  That is one of the simplest defenses
against a large scale attack that you can not do with src you can not
read/compile is change it so signature based attacks do not work.
Let's face it a custom compiled kernel/application is a significantly
lower security risk than a distribution kernel. (Considering the
person compiling the kernel is following a minimalist approach to
supporting his environment and is knowledgeable of GNU/Linux
development.

On 10/2/11, Guenter Roeck <guenter.roeck@ericsson.com> wrote:
> On Sun, Oct 02, 2011 at 02:36:05PM -0400, Randy Dunlap wrote:
>> On 10/02/11 04:54, Rafael J. Wysocki wrote:
>> > On Sunday, October 02, 2011, H. Peter Anvin wrote:
>> >> On 10/01/2011 06:04 PM, Rafael J. Wysocki wrote:
>> >>>
>> >>> OK, I'm taking this as "5 years is fine by us". :-)
>> >>>
>> >>> And the recommended procedure for rotating keys seems to be (1)
>> >>> generate
>> >>> a new key and (2) make as many people as you can sign it before the
>> >>> old
>> >>> one expires, right?
>> >>>
>> >>
>> >> (3) revoke the old key with a status code of "no longer in use", or
>> >> just
>> >> let it expire.
>> >>
>> >>>> Some people have decided to opt for an unlimited key, but that
>> >>>> *requires* that you have a way to revoke the old key, which is why we
>> >>>> are considering a key revocation escrow service.
>> >>>
>> >>> That service will be necessary anyway in case some keys are lost or
>> >>> compromised.
>> >>>
>> >>> I wonder what the procedure of restoring kernel.org access in case one
>> >>> has lost keys is supposed to be?
>> >>
>> >> Get a new key and get it re-signed.
>> >
>> > Hmm.  That doesn't seem very practical if someone doesn't live close
>> > to any other core kernel developers.
>> >
>> > What number of signatures on the key will be regarded as sufficient?
>> >
>> >> We can work out specific details at KS.
>> >
>> > Well, the KS is going to be busy time this year I suppose. :-)
>> >
>> > What about people who haven't been invited to the KS?
>>
>> They (we) should start building a web of trust with local key signings.
>> I'm already working on that in Portland, Oregon.
>>
> Anyone in Silicon Valley looking for key signings, please get in touch.
>
> Thanks,
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: kernel.org status: establishing a PGP web of trust

[Jeremy Fitzhardinge]

On 10/02/2011 04:27 PM, H. Peter Anvin wrote:
> On 10/02/2011 04:23 PM, Olof Johansson wrote:
>> On Sun, Oct 2, 2011 at 3:58 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 10/02/2011 03:54 PM, Guenter Roeck wrote:
>>>> Anyone in Silicon Valley looking for key signings, please get in touch.
>>>>
>>> I would be happy to be there, and I know Olof Johansson has been talking
>>> about one.
>>
>> Yeah, I don't think there's enough interest(?) to justify a full-blown
>> key signing party, but meeting up at a coffee shop or something sounds
>> like a good idea.
>>
> FWIW, Tuesday evening works really well for me.

How many people are in San Francisco?  I'm happy to head down to
Mountain View or somewhere similar to meet up some mid-afternoon though.

    J

Re: kernel.org status: establishing a PGP web of trust

[Dmitry Torokhov]

On Sun, Oct 02, 2011 at 05:44:49PM -0700, Jeremy Fitzhardinge wrote:
> On 10/02/2011 04:27 PM, H. Peter Anvin wrote:
> > On 10/02/2011 04:23 PM, Olof Johansson wrote:
> >> On Sun, Oct 2, 2011 at 3:58 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >>> On 10/02/2011 03:54 PM, Guenter Roeck wrote:
> >>>> Anyone in Silicon Valley looking for key signings, please get in touch.
> >>>>
> >>> I would be happy to be there, and I know Olof Johansson has been talking
> >>> about one.
> >>
> >> Yeah, I don't think there's enough interest(?) to justify a full-blown
> >> key signing party, but meeting up at a coffee shop or something sounds
> >> like a good idea.
> >>
> > FWIW, Tuesday evening works really well for me.
> 
> How many people are in San Francisco?  I'm happy to head down to
> Mountain View or somewhere similar to meet up some mid-afternoon though.

Yes, somewhere in Palo Alto/Mountnain View/Los Altos would work for me
as well.

Thanks.

-- 
Dmitry

Re: kernel.org status: establishing a PGP web of trust

[Guenter Roeck]

On Sun, Oct 02, 2011 at 08:44:49PM -0400, Jeremy Fitzhardinge wrote:
> On 10/02/2011 04:27 PM, H. Peter Anvin wrote:
> > On 10/02/2011 04:23 PM, Olof Johansson wrote:
> >> On Sun, Oct 2, 2011 at 3:58 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >>> On 10/02/2011 03:54 PM, Guenter Roeck wrote:
> >>>> Anyone in Silicon Valley looking for key signings, please get in touch.
> >>>>
> >>> I would be happy to be there, and I know Olof Johansson has been talking
> >>> about one.
> >>
> >> Yeah, I don't think there's enough interest(?) to justify a full-blown
> >> key signing party, but meeting up at a coffee shop or something sounds
> >> like a good idea.
> >>
> > FWIW, Tuesday evening works really well for me.
> 
> How many people are in San Francisco?  I'm happy to head down to
> Mountain View or somewhere similar to meet up some mid-afternoon though.
> 
Coming from the other side - south San Jose. Almost walking distance to hpa, small world
as it is. Mountain View would be fine for me, and Tuesday evening (or anytime else, really)
would work as well.

Guenter

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Sun, Oct 02, 2011 at 05:44:49PM -0700, Jeremy Fitzhardinge wrote:
> > FWIW, Tuesday evening works really well for me.
> 
> How many people are in San Francisco?  I'm happy to head down to
> Mountain View or somewhere similar to meet up some mid-afternoon though.

I could meet people Monday afternoon or evening in Mountain View;
contact me privately if you're interested.  Tuesday evening doesn't
work for me since I'm flying up to Portland for a LF board meeting on
Wednesday.

Both Peter and I have signed the new GPG key that Linus has created;
I can also verify folks for CACert.

						- Ted

Re: kernel.org status: establishing a PGP web of trust

[Ben Pfaff]

"H. Peter Anvin" <hpa@zytor.com> writes:

> 5. Get as many other kernel developers that you have physical access to
>    to sign your key after verifying the fingerprint.  Verifying keys
>    over the phone is OK if and only if you know them *extremely* well;
>    think "would I be willing to testify in court that the person I
>    talked to was X"?

There is already an extensive Debian web of trust, and along with
it a keysigning coordination effort and even a long list of
Debian developers who offer to sign keys, with their physical
locations and email addresses:
        http://wiki.debian.org/Keysigning/Offers

I wonder whether either effort would benefit from joining forces?
I am also sure that there is overlap between Debian developers
and kernel developers.
-- 
Ben Pfaff 
http://benpfaff.org

Re: kernel.org status: establishing a PGP web of trust

[Jeremy Fitzhardinge]

On 10/02/2011 06:09 PM, Ted Ts'o wrote:
> On Sun, Oct 02, 2011 at 05:44:49PM -0700, Jeremy Fitzhardinge wrote:
>>> FWIW, Tuesday evening works really well for me.
>> How many people are in San Francisco?  I'm happy to head down to
>> Mountain View or somewhere similar to meet up some mid-afternoon though.
> I could meet people Monday afternoon or evening in Mountain View;
> contact me privately if you're interested.  Tuesday evening doesn't
> work for me since I'm flying up to Portland for a LF board meeting on
> Wednesday.

Monday afternoon would suit me perfectly.  Where abouts?  Somewhere like
Red Rock cafe at 3pm?

    J

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 06:09 PM, Ted Ts'o wrote:
> On Sun, Oct 02, 2011 at 05:44:49PM -0700, Jeremy Fitzhardinge wrote:
>>> FWIW, Tuesday evening works really well for me.
>>
>> How many people are in San Francisco?  I'm happy to head down to
>> Mountain View or somewhere similar to meet up some mid-afternoon though.
> 
> I could meet people Monday afternoon or evening in Mountain View;
> contact me privately if you're interested.  Tuesday evening doesn't
> work for me since I'm flying up to Portland for a LF board meeting on
> Wednesday.
> 
> Both Peter and I have signed the new GPG key that Linus has created;
> I can also verify folks for CACert.
> 

Junio and a few others have tried to get a keysigning together for the
Google MTV people ... if we could do that on Monday that would be a
really good thing.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Andrew Morton]

On Sun, 02 Oct 2011 18:22:07 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:

> On 10/02/2011 06:09 PM, Ted Ts'o wrote:
> > On Sun, Oct 02, 2011 at 05:44:49PM -0700, Jeremy Fitzhardinge wrote:
> >>> FWIW, Tuesday evening works really well for me.
> >>
> >> How many people are in San Francisco?  I'm happy to head down to
> >> Mountain View or somewhere similar to meet up some mid-afternoon though.
> > 
> > I could meet people Monday afternoon or evening in Mountain View;
> > contact me privately if you're interested.  Tuesday evening doesn't
> > work for me since I'm flying up to Portland for a LF board meeting on
> > Wednesday.
> > 
> > Both Peter and I have signed the new GPG key that Linus has created;
> > I can also verify folks for CACert.
> > 
> 
> Junio and a few others have tried to get a keysigning together for the
> Google MTV people ... if we could do that on Monday that would be a
> really good thing.

That works for me.  Please let us know precisely what preparatory
things need to be done?

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 06:42 PM, Andrew Morton wrote:
>>
>> Junio and a few others have tried to get a keysigning together for the
>> Google MTV people ... if we could do that on Monday that would be a
>> really good thing.
> 
> That works for me.  Please let us know precisely what preparatory
> things need to be done?

1. Find a place to meet.  If available, maybe we could get a conference
room at Google for the actual meet-up (might be a bit more practical
than meeting in a cafe with laptops and all.)

2. Collect people's key IDs and download them from the keyserver.

3. Print out enough copies of the fingerprints on paper.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/02/2011 06:18 PM, Ben Pfaff wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>> 5. Get as many other kernel developers that you have physical access to
>>    to sign your key after verifying the fingerprint.  Verifying keys
>>    over the phone is OK if and only if you know them *extremely* well;
>>    think "would I be willing to testify in court that the person I
>>    talked to was X"?
> 
> There is already an extensive Debian web of trust, and along with
> it a keysigning coordination effort and even a long list of
> Debian developers who offer to sign keys, with their physical
> locations and email addresses:
>         http://wiki.debian.org/Keysigning/Offers
> 
> I wonder whether either effort would benefit from joining forces?
> I am also sure that there is overlap between Debian developers
> and kernel developers.

There almost certainly is, and keep in mind that there isn't really "a
Debian web of trust" and "a kernel web of trust"... there is a "PGP web
of trust" as long as people upload their signatures to the shared
keyserver system.

	-hpaq

Re: kernel.org status: establishing a PGP web of trust

[Geoff Levand]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On 10/02/2011 06:43 PM, H. Peter Anvin wrote:
> On 10/02/2011 06:42 PM, Andrew Morton wrote:
>>>
>>> Junio and a few others have tried to get a keysigning together for the
>>> Google MTV people ... if we could do that on Monday that would be a
>>> really good thing.
>> 
>> That works for me.  Please let us know precisely what preparatory
>> things need to be done?
> 
> 1. Find a place to meet.  If available, maybe we could get a conference
> room at Google for the actual meet-up (might be a bit more practical
> than meeting in a cafe with laptops and all.)

So would this be just for Google people, or can the general public come?

-Geoff



[-- Attachment #2: 0x2E141B16.asc --]
[-- Type: application/pgp-keys, Size: 9418 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Sun, Oct 02, 2011 at 08:15:01PM -0700, Geoff Levand wrote:
> > 1. Find a place to meet.  If available, maybe we could get a conference
> > room at Google for the actual meet-up (might be a bit more practical
> > than meeting in a cafe with laptops and all.)
> 
> So would this be just for Google people, or can the general public come?

The one which I'm setting up for tomorrow (Monday) at 2pm can be for
non-Google who are local to Mountain View as well.  I'd ask you to
show up 5 minutes early so I can meet you at the lobby and sign you
in.

	      	       	    	       - Ted

Re: kernel.org status: establishing a PGP web of trust

[Dmitry Torokhov]

On Sunday, October 02, 2011 08:29:34 PM Ted Ts'o wrote:
> On Sun, Oct 02, 2011 at 08:15:01PM -0700, Geoff Levand wrote:
> > > 1. Find a place to meet.  If available, maybe we could get a
> > > conference room at Google for the actual meet-up (might be a bit
> > > more practical than meeting in a cafe with laptops and all.)
> > 
> > So would this be just for Google people, or can the general public
> > come?
> 
> The one which I'm setting up for tomorrow (Monday) at 2pm can be for
> non-Google who are local to Mountain View as well.  I'd ask you to
> show up 5 minutes early so I can meet you at the lobby and sign you
> in.

What building is this? I'd like to stop by as well...

-- 
Dmitry

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Sun, Oct 02, 2011 at 08:38:27PM -0700, Dmitry Torokhov wrote:
> On Sunday, October 02, 2011 08:29:34 PM Ted Ts'o wrote:
> > On Sun, Oct 02, 2011 at 08:15:01PM -0700, Geoff Levand wrote:
> > > > 1. Find a place to meet.  If available, maybe we could get a
> > > > conference room at Google for the actual meet-up (might be a bit
> > > > more practical than meeting in a cafe with laptops and all.)
> > > 
> > > So would this be just for Google people, or can the general public
> > > come?
> > 
> > The one which I'm setting up for tomorrow (Monday) at 2pm can be for
> > non-Google who are local to Mountain View as well.  I'd ask you to
> > show up 5 minutes early so I can meet you at the lobby and sign you
> > in.
> 
> What building is this? I'd like to stop by as well...

I'll send out directions to the building on the Mountain View campus
when people send me their key id's, so I can have some idea how many
people will be showing up.

					- Ted

Re: kernel.org status: establishing a PGP web of trust

[Andrew Morton]

On Sun, 2 Oct 2011 23:54:55 -0400 "Ted Ts'o" <tytso@mit.edu> wrote:

> On Sun, Oct 02, 2011 at 08:38:27PM -0700, Dmitry Torokhov wrote:
> > On Sunday, October 02, 2011 08:29:34 PM Ted Ts'o wrote:
> > > On Sun, Oct 02, 2011 at 08:15:01PM -0700, Geoff Levand wrote:
> > > > > 1. Find a place to meet.  If available, maybe we could get a
> > > > > conference room at Google for the actual meet-up (might be a bit
> > > > > more practical than meeting in a cafe with laptops and all.)
> > > > 
> > > > So would this be just for Google people, or can the general public
> > > > come?
> > > 
> > > The one which I'm setting up for tomorrow (Monday) at 2pm can be for
> > > non-Google who are local to Mountain View as well.  I'd ask you to
> > > show up 5 minutes early so I can meet you at the lobby and sign you
> > > in.
> > 
> > What building is this? I'd like to stop by as well...
> 
> I'll send out directions to the building on the Mountain View campus
> when people send me their key id's, so I can have some idea how many
> people will be showing up.
> 

Guys, I for one haven't had to futz with key generation in at least
five years.

Please, tell us (or me, at least) what to do.  As in "type this".

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Sun, Oct 02, 2011 at 09:02:15PM -0700, Andrew Morton wrote:
> 
> Guys, I for one haven't had to futz with key generation in at least
> five years.
> 
> Please, tell us (or me, at least) what to do.  As in "type this".

Step-by-step instructions can be found here:

http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html#prep

							- Ted

Re: kernel.org status: establishing a PGP web of trust

[Steven Rostedt]

On Sat, Oct 01, 2011 at 07:05:19AM -0700, Greg KH wrote:
> 
> I would recommend a physical access device for your new gpg key that you
> create.  I've heard good things about this USB device:
> 	http://www.crypto-stick.org/
> and am trying to have a bunch of them at the Kernel Summit this year to
> hand out to people if they want one.

Hmm, if I'm going to get one at KS, should I stop getting signed keys
now? A few of us have already started the GPG song and dance to get
signed keys over the phone (where we know each other enough to know
phone numbers and recognize voices).

But I did it all wrong. I have a 4k RSA key for both signing and
encrypting with no revoke generated and no expiration. The key is
currently on one of my machines, which I was about to move to an
encrypted usb device.

If I can get one of these devices, it sounds like I should create a new
key on it as my master key and start using subkeys as described in the
debian link that someone posted before. Then at the keysigning I would
just use the key from this device.


> 
> There are also lots of other smart-card form-factor devices that can be
> used to store GPG keys.  Some places to purchase these can be found at
> links from the above site.

I just pulled out an old GNU GPG card I had, and unfortunately it only
supports 1024 RSA keys.

-- Steve

Re: kernel.org status: hints on how to check your machine for intrusion

[Maarten Lankhorst]

On 10/01/2011 11:30 PM, Henrique de Moraes Holschuh wrote:
> Hmm, and a last tip:
>
> Always use the "AllowUsers" or "AllowGroups" directive in sshd_config to
> only allow access to whitelisted users/groups and deny to every other user
> (including system ones).
>
Also nice is a dumb iptables filter with the recent match. 2 lines total.
http://www.linux-noob.com/forums/index.php?/topic/1829-ssh-rate-limit-per-ip-new-method/

But denyhosts does blacklisting for sshd automatically. :)
http://denyhosts.sourceforge.net/faq.html

~Maarten

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Sun, Oct 02, 2011 at 10:53:59AM -0700, H. Peter Anvin wrote:
> On 10/02/2011 04:54 AM, Rafael J. Wysocki wrote:
> > On Sunday, October 02, 2011, H. Peter Anvin wrote:
> > 
> > Hmm.  That doesn't seem very practical if someone doesn't live close
> > to any other core kernel developers.
> > 
> 
> You probably know enough people (including myself) that would be willing
> to sign your key over the phone.
>...

You have personally checked Rafael's user id (e.g. passport)?

This might or might not be true in this case, but generally signing keys 
without having ever checked the user id (no matter how long you know the 
person) is a common mistake.

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: hints on how to check your machine for intrusion

[gmack]

> Date: Sat, 01 Oct 2011 14:45:38 -0400
> From: Steven Rostedt <rostedt@goodmis.org>
> To: David Miller <davem@davemloft.net>
> Cc: w@1wt.eu, greg@kroah.com, linux-kernel@vger.kernel.org
> Subject: Re: kernel.org status: hints on how to check your machine for
>     intrusion
> 
> On Sat, 2011-10-01 at 14:40 -0400, Steven Rostedt wrote:
> > OK, I decided to attach the perl script anyway. It is very crude, and
> > really needs to be cleaned up for generic use.
> > 
> 
> I've just been pointed to:
> 
> http://www.fail2ban.org/wiki/index.php/Main_Page
> 
> This looks like something similar.
> 
> You see, the reason I posted this tool is because I was sure people will
> point me to better ones that do the same thing (and more!)   ;)
> 

The nice thing about fail2ban is that you can use it to montitor other 
ports since many bots are now doing ftp/smtp sasl/imap/imaps/pop3/pop3s 
scans to find system accounts and then use the result for an ssh login.

As a warning though, at least on debian the SMTP SASL regex is non 
functional and I haven't had time to work out a working one so hopefully 
if someone has one it would be helpful. A fix for this is doubly important 
since the SASL package has a memory leak on failed login that they have 
known about for at least 3 years but haven't bothered fixing.  A scanning 
bot can take up several gigs of memory in about an hour.

	Gerhard


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer, I find your faith in technology amusing.

Re: kernel.org status: hints on how to check your machine for intrusion

[gmack]

On Sat, 1 Oct 2011, Frank A. Kingswood wrote:
> On 01/10/11 19:06, Steven Rostedt wrote:
> > On Sat, Oct 01, 2011 at 09:35:33AM +0200, Willy Tarreau wrote:
> > > 
> > For my machine that is connected to the outside world, I have a script
> > that runs every night that checks for attacks. As bots constantly look
> > for port 22 and 80, they find my machine without issue. When my script
> > detects a bunch of ssh login attempts that fail, it will add that ip
> > address to the iptables DROP chain:
> > 
> > # iptables -L -n | grep DROP | wc -l
> > 2656
> > 
> > I've picked up quite a few ;)
> > 
> > This script only runs and scans once at night. Probably better to have
> > it run more often.
> 
> Limiting SSH accesses to a few a minute (failed or not) is useful to block
> many password guess attacks. I set up mine a long time ago following this
> article using "recent" matches in iptables:
> 
> http://www.debian-administration.org/articles/187
> 
> You'll want to set the same rules for ipv6.
> 
> This won't stop low frequency and distributed attacks, and sometimes but
> extremely rarely I find myself connecting more quickly than the rate limit.

Too easy to hit the rate limit if you work in an office full of people who 
use scp for file uploads.

	Gerhard


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer, I find your faith in technology amusing.

Re: kernel.org status: establishing a PGP web of trust

[Jonathan Cameron]

On 10/02/11 23:54, Guenter Roeck wrote:
> On Sun, Oct 02, 2011 at 02:36:05PM -0400, Randy Dunlap wrote:
>> On 10/02/11 04:54, Rafael J. Wysocki wrote:
>>> On Sunday, October 02, 2011, H. Peter Anvin wrote:
>>>> On 10/01/2011 06:04 PM, Rafael J. Wysocki wrote:
>>>>>
>>>>> OK, I'm taking this as "5 years is fine by us". :-)
>>>>>
>>>>> And the recommended procedure for rotating keys seems to be (1) generate
>>>>> a new key and (2) make as many people as you can sign it before the old
>>>>> one expires, right?
>>>>>
>>>>
>>>> (3) revoke the old key with a status code of "no longer in use", or just
>>>> let it expire.
>>>>
>>>>>> Some people have decided to opt for an unlimited key, but that
>>>>>> *requires* that you have a way to revoke the old key, which is why we
>>>>>> are considering a key revocation escrow service.
>>>>>
>>>>> That service will be necessary anyway in case some keys are lost or
>>>>> compromised.
>>>>>
>>>>> I wonder what the procedure of restoring kernel.org access in case one
>>>>> has lost keys is supposed to be?
>>>>
>>>> Get a new key and get it re-signed.
>>>
>>> Hmm.  That doesn't seem very practical if someone doesn't live close
>>> to any other core kernel developers.
>>>
>>> What number of signatures on the key will be regarded as sufficient?
>>>
>>>> We can work out specific details at KS.
>>>
>>> Well, the KS is going to be busy time this year I suppose. :-)
>>>
>>> What about people who haven't been invited to the KS?
>>
>> They (we) should start building a web of trust with local key signings.
>> I'm already working on that in Portland, Oregon.
>>
> Anyone in Silicon Valley looking for key signings, please get in touch.

Similarly anyone Cambridge UK based (or London I guess) please get in touch.

Re: kernel.org status: establishing a PGP web of trust

[Jiri Kosina]

On Fri, 30 Sep 2011, H. Peter Anvin wrote:

> Since the kernel.org status announcement last week a number of you
> have contacted me about re-establishing credentials.  In order to
> establish a proper PGP web of trust we need keys that are cross-signed
> by other developers.  As such, we ask that you follow the following
> steps:
> 
> 1. Make sure your systems are uncompromised.  We will address specific
>    recommended steps for that in a separate email.
> 
> 2. Create a new PGP/GPG key, and also generate a key revocation
>    certificate (but don't import it anywhere -- save it for the
>    future) for your new key.  In the near future we are considering
>    setting up an escrow service for key revocation certificates.
> 
>    I recommend using a 4096-bit RSA key.  Given how fast computers are
>    these days, there is no reason to use a shorter key.  DSA keys
>    should be considered obsolete; substantial weaknesses have been
>    found in DSA.
> 
>    $ gpg --gen-key
>    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
> 
> 3. If you are reasonably certain that your old key has never been
>    jeopardized, sign the new key with the old key.

I have a question here. In case people are 'reasonably certain' that the 
old key has never been jeoparadized, why are they required to create a new 
key?

(if the old key would have been compromised, the attacker could as well 
generate a new key and sign it with the old key himself, so I fail to see 
any benefit of this PGP excercise).

It doesn't make too much sense to force people to live with two different 
personalities in this "PGP web of trust" world just for the sake of 
kernel.org, does it?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Mon, Oct 03, 2011 at 05:14:30AM -0400, Steven Rostedt wrote:
> On Sat, Oct 01, 2011 at 07:05:19AM -0700, Greg KH wrote:
> > 
> > I would recommend a physical access device for your new gpg key that you
> > create.  I've heard good things about this USB device:
> > 	http://www.crypto-stick.org/
> > and am trying to have a bunch of them at the Kernel Summit this year to
> > hand out to people if they want one.
> 
> Hmm, if I'm going to get one at KS, should I stop getting signed keys
> now? A few of us have already started the GPG song and dance to get
> signed keys over the phone (where we know each other enough to know
> phone numbers and recognize voices).

You can put a key into the device, and then delete it from your
computer, so you don't have to create the key in the device.

Hope this helps,

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[Steven Rostedt]

On Mon, 2011-10-03 at 07:13 -0700, Greg KH wrote:
> On Mon, Oct 03, 2011 at 05:14:30AM -0400, Steven Rostedt wrote:
> > On Sat, Oct 01, 2011 at 07:05:19AM -0700, Greg KH wrote:
> > > 
> > > I would recommend a physical access device for your new gpg key that you
> > > create.  I've heard good things about this USB device:
> > > 	http://www.crypto-stick.org/
> > > and am trying to have a bunch of them at the Kernel Summit this year to
> > > hand out to people if they want one.
> > 
> > Hmm, if I'm going to get one at KS, should I stop getting signed keys
> > now? A few of us have already started the GPG song and dance to get
> > signed keys over the phone (where we know each other enough to know
> > phone numbers and recognize voices).
> 
> You can put a key into the device, and then delete it from your
> computer, so you don't have to create the key in the device.

OK, then I'll go with my old plan to take my current key and put it on
an encrypted USB stick and remove it from my main machine. When I get
this new device, I'll add it to that device and use it afterward.

Thanks!

-- Steve

Re: kernel.org status: establishing a PGP web of trust

[Frank Ch. Eigler]

bunk@stusta.de wrote:

> [...]
>> You probably know enough people (including myself) that would be willing
>> to sign your key over the phone.
>>...
>
> You have personally checked Rafael's user id (e.g. passport)?
>
> This might or might not be true in this case, but generally signing keys 
> without having ever checked the user id (no matter how long you know the 
> person) is a common mistake.

What is the threat that this passport checking is intended to cure?
That someone else might have been impersonating Rafael for years,
sending patches, chatting in email and over the phone, and attending
conferences?  If so, perhaps the impostor is of more value to the
project than the Real Rafael.

- FChE

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Fri, Sep 30, 2011 at 04:50:37PM -0700, H. Peter Anvin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> Since the kernel.org status announcement last week a number of you
> have contacted me about re-establishing credentials.  In order to
> establish a proper PGP web of trust we need keys that are cross-signed
> by other developers.  As such, we ask that you follow the following
> steps:
>...
> 5. Get as many other kernel developers that you have physical access to
>    to sign your key after verifying the fingerprint.  Verifying keys
>    over the phone is OK if and only if you know them *extremely* well;
>    think "would I be willing to testify in court that the person I
>    talked to was X"?
> 
>    If you work in an office with multiple other Linux developers, it
>    would be a very good thing to organize a local key signing.  We will
>    do a key signing at Kernel Summit for the core kernel developers.
> 
>    A web site with recommendations for running a key signing:
> 
> 
> http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html
> 
>    $ gpg --fingerprint <key ID>
>    $ gpg --keyserver pgp.mit.edu --recv-key <their key ID>
>    $ gpg -u <your key ID> --sign-key <their key ID>
>    $ gpg --keyserver pgp.mit.edu --send-key <their key ID>
>    $ gpg --keyserver pgp.mit.edu --recv-key <your key ID>
> 
> 6. Please send me the key identifier and fingerprint to
>    <keys@zytor.com>.  This is a temporary address until the kernel.org
>    MX is ready to put back online; eventually we will probably have a
>    web form interface for this.

What are the exact technical requirements for key acceptance?

"as many other kernel developers" is quite vague, starting with the fact 
that there is not a clear definition of "kernel developer"...

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Mon, Oct 03, 2011 at 12:28:17PM -0400, Frank Ch. Eigler wrote:
> 
> bunk@stusta.de wrote:
> 
> > [...]
> >> You probably know enough people (including myself) that would be willing
> >> to sign your key over the phone.
> >>...
> >
> > You have personally checked Rafael's user id (e.g. passport)?
> >
> > This might or might not be true in this case, but generally signing keys 
> > without having ever checked the user id (no matter how long you know the 
> > person) is a common mistake.
> 
> What is the threat that this passport checking is intended to cure?
> That someone else might have been impersonating Rafael for years,
> sending patches, chatting in email and over the phone, and attending
> conferences?

Key signing is an identity check.

> If so, perhaps the impostor is of more value to the
> project than the Real Rafael.

Pseudonymous contributions to the kernel are not allowed.

> - FChE

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Josh Triplett]

On Mon, Oct 03, 2011 at 01:19:27PM +0200, Jiri Kosina wrote:
> On Fri, 30 Sep 2011, H. Peter Anvin wrote:
> 
> > Since the kernel.org status announcement last week a number of you
> > have contacted me about re-establishing credentials.  In order to
> > establish a proper PGP web of trust we need keys that are cross-signed
> > by other developers.  As such, we ask that you follow the following
> > steps:
> > 
> > 1. Make sure your systems are uncompromised.  We will address specific
> >    recommended steps for that in a separate email.
> > 
> > 2. Create a new PGP/GPG key, and also generate a key revocation
> >    certificate (but don't import it anywhere -- save it for the
> >    future) for your new key.  In the near future we are considering
> >    setting up an escrow service for key revocation certificates.
> > 
> >    I recommend using a 4096-bit RSA key.  Given how fast computers are
> >    these days, there is no reason to use a shorter key.  DSA keys
> >    should be considered obsolete; substantial weaknesses have been
> >    found in DSA.
> > 
> >    $ gpg --gen-key
> >    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
> > 
> > 3. If you are reasonably certain that your old key has never been
> >    jeopardized, sign the new key with the old key.
> 
> I have a question here. In case people are 'reasonably certain' that the 
> old key has never been jeoparadized, why are they required to create a new 
> key?
[...]
> It doesn't make too much sense to force people to live with two different 
> personalities in this "PGP web of trust" world just for the sake of 
> kernel.org, does it?

Same question here.  I have a key, which has already accumulated some
signatures, and I feel confident that key remains secure, along with the
one and only system that key lives on.  I have a revocation certificate
prepared for that key in a secure location, though I'd certainly welcome
an escrow service from kernel.org as long as that service only stored
encrypted documents to which only the key owner had the passphrase.  I
don't see any need to generate an entirely new key in a hurry.
Certainly transitioning to larger and algorithmically better keys over
time seems like a good idea, but given the nature of the kernel.org
compromise, immediate concerns about the strength of GPG keys seems much
less warranted than concerns about the security of the systems they live
on.

- Josh Triplett

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Mon, Oct 03, 2011 at 03:56:52PM -0700, Josh Triplett wrote:
> 
> Same question here.  I have a key, which has already accumulated some
> signatures, and I feel confident that key remains secure, along with the
> one and only system that key lives on.  I have a revocation certificate
> prepared for that key in a secure location, though I'd certainly welcome
> an escrow service from kernel.org as long as that service only stored
> encrypted documents to which only the key owner had the passphrase.  I
> don't see any need to generate an entirely new key in a hurry.
> Certainly transitioning to larger and algorithmically better keys over
> time seems like a good idea, but given the nature of the kernel.org
> compromise, immediate concerns about the strength of GPG keys seems much
> less warranted than concerns about the security of the systems they live
> on.

This is what I did.  I generated a new key a year ago, which has never
left my laptop.  I accumulated keys at linux.conf.au, and after I get
more signatures at the KS in Prague, my intention is to gradually
transition from the key generated in 1997, which has been used to sign
all of my Debian packages and e2fsprogs releases, to my new key.

But that's only because I'm reasonably confident I can trust my new
key, and I did a very careful examination of my laptop looking for
signs that my machines might have been penetrated --- before I
reinstalled it and my desktop at the same time, and initiated a full
password change cycle.  (Yes, that's paranoia.  With security, the
question is always, "are you paranoid *enough*"?)

Note that if your laptop allows incoming ssh connections, and you
logged into master.kernel.org with ssh forwarding enabled, your laptop
may not be safe.  So be very, very careful before you assume that your
laptop is safe.  At least one kernel developer, after he got past the
belief, "surely I could have never had my machine be compromised",
looked carefully and found rootkits on his machines.

       		     	   	       - Ted

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/03/2011 09:49 PM, Ted Ts'o wrote:
> 
> Note that if your laptop allows incoming ssh connections, and you
> logged into master.kernel.org with ssh forwarding enabled, your laptop
> may not be safe.  So be very, very careful before you assume that your
> laptop is safe.  At least one kernel developer, after he got past the
> belief, "surely I could have never had my machine be compromised",
> looked carefully and found rootkits on his machines.
> 
>        		     	   	       - Ted

By the way, I'm now pretty convinced that allowing inbound ssh on
laptops (which is the default on all the mainline Linux distros as far
as I know) is seriously broken... laptops get connected to *extremely*
insecure networks on just way too regular a basis.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Mon, Oct 03, 2011 at 09:52:29PM -0700, H. Peter Anvin wrote:
> On 10/03/2011 09:49 PM, Ted Ts'o wrote:
> > 
> > Note that if your laptop allows incoming ssh connections, and you
> > logged into master.kernel.org with ssh forwarding enabled, your laptop
> > may not be safe.  So be very, very careful before you assume that your
> > laptop is safe.  At least one kernel developer, after he got past the
> > belief, "surely I could have never had my machine be compromised",
> > looked carefully and found rootkits on his machines.
> > 
> By the way, I'm now pretty convinced that allowing inbound ssh on
> laptops (which is the default on all the mainline Linux distros as far
> as I know) is seriously broken... laptops get connected to *extremely*
> insecure networks on just way too regular a basis.

+1000

I'll note though that at least some Linux distributions when
customized by corporate security types tend to disable incoming ssh.
If your company doesn't, it probably should... 

... and it should definitely raise a firewall and disable NAT and
incoming ssh if you're connected to the corporate VPN.  I once heard a
story several years back when someone I knew was staying at a hotel in
Beaverton, and connected to an open WiFi access point to get internet
access.  Very shortly there afterwards, he realized he was connected
behind the Intel corporate firewall, at which point he (not being an
Intel employee, and conscious of the Business Conduct Guidelines that
he was require to sign every year) disconnected as quickly as
possible.

Oops.  :-)

						- Ted

Re: kernel.org status: establishing a PGP web of trust

[Jiri Kosina]

On Mon, 3 Oct 2011, H. Peter Anvin wrote:

> By the way, I'm now pretty convinced that allowing inbound ssh on
> laptops (which is the default on all the mainline Linux distros as far
> as I know) is seriously broken... laptops get connected to *extremely*
> insecure networks on just way too regular a basis.

Well, not all mainline Linux distributions do this. opensuse, to name one 
example, by default does not start sshd (and there have been quite some 
flames when this has been introduced :) ).

-- 
Jiri Kosina
SUSE Labs

Re: kernel.org status: establishing a PGP web of trust

[Heiko Carstens]

On Mon, Oct 03, 2011 at 01:19:27PM +0200, Jiri Kosina wrote:
> On Fri, 30 Sep 2011, H. Peter Anvin wrote:
> 
> > Since the kernel.org status announcement last week a number of you
> > have contacted me about re-establishing credentials.  In order to
> > establish a proper PGP web of trust we need keys that are cross-signed
> > by other developers.  As such, we ask that you follow the following
> > steps:
> > 
> > 1. Make sure your systems are uncompromised.  We will address specific
> >    recommended steps for that in a separate email.
> > 
> > 2. Create a new PGP/GPG key, and also generate a key revocation
> >    certificate (but don't import it anywhere -- save it for the
> >    future) for your new key.  In the near future we are considering
> >    setting up an escrow service for key revocation certificates.
> > 
> >    I recommend using a 4096-bit RSA key.  Given how fast computers are
> >    these days, there is no reason to use a shorter key.  DSA keys
> >    should be considered obsolete; substantial weaknesses have been
> >    found in DSA.
> > 
> >    $ gpg --gen-key
> >    $ gpg -u <key ID> -o <key ID>.revoke --gen-revoke
> > 
> > 3. If you are reasonably certain that your old key has never been
> >    jeopardized, sign the new key with the old key.
> 
> I have a question here. In case people are 'reasonably certain' that the 
> old key has never been jeoparadized, why are they required to create a new 
> key?
> 
> (if the old key would have been compromised, the attacker could as well 
> generate a new key and sign it with the old key himself, so I fail to see 
> any benefit of this PGP excercise).
> 
> It doesn't make too much sense to force people to live with two different 
> personalities in this "PGP web of trust" world just for the sake of 
> kernel.org, does it?

Also same question here. And as far as I can tell nobody has given an
answer yet.

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/03/2011 10:11 PM, Ted Ts'o wrote:
> 
> I'll note though that at least some Linux distributions when
> customized by corporate security types tend to disable incoming ssh.
> If your company doesn't, it probably should... 
> 

I wasn't really referring to corporate customized versions but to what
comes out of the stock distro, which is probably what most users run.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Tuesday, October 04, 2011, H. Peter Anvin wrote:
> On 10/03/2011 09:49 PM, Ted Ts'o wrote:
> > 
> > Note that if your laptop allows incoming ssh connections, and you
> > logged into master.kernel.org with ssh forwarding enabled, your laptop
> > may not be safe.  So be very, very careful before you assume that your
> > laptop is safe.  At least one kernel developer, after he got past the
> > belief, "surely I could have never had my machine be compromised",
> > looked carefully and found rootkits on his machines.
> > 
> >        		     	   	       - Ted
> 
> By the way, I'm now pretty convinced that allowing inbound ssh on
> laptops (which is the default on all the mainline Linux distros as far
> as I know) is seriously broken... laptops get connected to *extremely*
> insecure networks on just way too regular a basis.

That's very true.

I'd recommend everyone to run a full nmap scan of his/her laptop
and to block everything it finds open before using it outside of the home
network.

Thanks,
Rafael

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

On Mon, 03 Oct 2011 21:04:41 +0300, Adrian Bunk said:
> On Mon, Oct 03, 2011 at 12:28:17PM -0400, Frank Ch. Eigler wrote:

> > What is the threat that this passport checking is intended to cure?
> > That someone else might have been impersonating Rafael for years,
> > sending patches, chatting in email and over the phone, and attending
> > conferences?
>
> Key signing is an identity check.

That's dodging the issue. Somehow, I don't see Andrew Morton asking Linus to
sign his key, and Linus saying "How do I know you're the *real* Andrew Morton?"
And Andrew is a clever guy, if he was a fake Andrew, I'm sure he'd have gotten
a fake ID that would be good enough to fool Linus, who is also a clever guy but
I'm not aware of any special background he has in forgery detection. ;)

The more important point is that as far as the linux-kernel community is
concerned, the guy we've all seen show up at conferences and present stuff all
these times *is* Andrew Morton, even if his real name is George Q. Smith and
he's been on the run for the last 27 years for an embarassing incident
involving an ostrich, the mayor's daughter, and 17 gallons of mineral oil in
the atrium of the museum. ;)

The ID check is  to connect an actual person to the claimed key, and primarily
intended for key signing parties and the like, where people *don't* know each
other very well. I think there's something like 5 people on the linux-kernel
list who actually know me in real life, because I don't travel much and I'm
rather in the boonies.  If I asked anybody *else* who I'd not met before to
sign my key, yes, I'd expect them to check my ID, to ensure I wasn't somebody
trying to pull a fast one at the keysigning party.

> > If so, perhaps the impostor is of more value to the
> > project than the Real Rafael.
> 
> Pseudonymous contributions to the kernel are not allowed.

See above - whoever Andrew Morton *really* is, his contributions are hardly
pseudonymous.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Jiri Kosina]

On Tue, 4 Oct 2011, Heiko Carstens wrote:

> > I have a question here. In case people are 'reasonably certain' that the 
> > old key has never been jeoparadized, why are they required to create a new 
> > key?
> > 
> > (if the old key would have been compromised, the attacker could as well 
> > generate a new key and sign it with the old key himself, so I fail to see 
> > any benefit of this PGP excercise).
> > 
> > It doesn't make too much sense to force people to live with two different 
> > personalities in this "PGP web of trust" world just for the sake of 
> > kernel.org, does it?
> 
> Also same question here. And as far as I can tell nobody has given an
> answer yet.

In the meantime, at least one reason came up in parallel discussion ... a 
lot of people have those oldish keys generated as 1024bit or so, and using 
DSA.

And it seems like 4096/RSA is sort of required here.

-- 
Jiri Kosina
SUSE Labs

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/04/2011 03:02 PM, Jiri Kosina wrote:
> 
> In the meantime, at least one reason came up in parallel discussion ... a 
> lot of people have those oldish keys generated as 1024bit or so, and using 
> DSA.
> 
> And it seems like 4096/RSA is sort of required here.
> 

If nothing else it should be considered modern practice.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: kernel.org status: establishing a PGP web of trust

[Ralf Baechle]

On Mon, Oct 03, 2011 at 10:53:58AM +0100, Jonathan Cameron wrote:

> Similarly anyone Cambridge UK based (or London I guess) please get in touch.

That would be me and a few more here in Cambridge.

  Ralf

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Tue, Oct 04, 2011 at 04:29:48PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 03 Oct 2011 21:04:41 +0300, Adrian Bunk said:
> > On Mon, Oct 03, 2011 at 12:28:17PM -0400, Frank Ch. Eigler wrote:
> 
> > > What is the threat that this passport checking is intended to cure?
> > > That someone else might have been impersonating Rafael for years,
> > > sending patches, chatting in email and over the phone, and attending
> > > conferences?
> >
> > Key signing is an identity check.
> 
> That's dodging the issue. Somehow, I don't see Andrew Morton asking Linus to
> sign his key, and Linus saying "How do I know you're the *real* Andrew Morton?"
> And Andrew is a clever guy, if he was a fake Andrew, I'm sure he'd have gotten
> a fake ID that would be good enough to fool Linus, who is also a clever guy but
> I'm not aware of any special background he has in forgery detection. ;)
> 
> The more important point is that as far as the linux-kernel community is
> concerned, the guy we've all seen show up at conferences and present stuff all
> these times *is* Andrew Morton, even if his real name is George Q. Smith and
> he's been on the run for the last 27 years for an embarassing incident
> involving an ostrich, the mayor's daughter, and 17 gallons of mineral oil in
> the atrium of the museum. ;)
> 
> The ID check is  to connect an actual person to the claimed key, and primarily
> intended for key signing parties and the like, where people *don't* know each
> other very well. I think there's something like 5 people on the linux-kernel
> list who actually know me in real life, because I don't travel much and I'm
> rather in the boonies.  If I asked anybody *else* who I'd not met before to
> sign my key, yes, I'd expect them to check my ID, to ensure I wasn't somebody
> trying to pull a fast one at the keysigning party.

If you just want to be sure that patch number 100 comes from the same
person as the 99 patches before you could do that without key signing 
(require signed patches and check that all 100 patches were signed by
 the same key).

But the semantics of PGP key signing is that you certify that you 
verified that a photo ID of that person matches the name on the key.

No matter if that's needed for kernel purposes.
And no matter if it's possible to present you a fake ID.

One might discuss what requirements for access to kernel.org machines make 
sense or not, but when you sign a key you have to check a photo ID first.

> > > If so, perhaps the impostor is of more value to the
> > > project than the Real Rafael.
> > 
> > Pseudonymous contributions to the kernel are not allowed.
> 
> See above - whoever Andrew Morton *really* is, his contributions are hardly
> pseudonymous.

Each time a patch goes through him into the kernel, he certifies that 
his real name is Andrew Morton.

If that would not be his real name, it would make him somewhere between 
completely untrustable and punishable at court.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

Hi -

On Wed, Oct 05, 2011 at 01:39:32AM +0300, Adrian Bunk wrote:

> [...]  But the semantics of PGP key signing is that you certify that
> you verified that a photo ID of that person matches the name on the
> key.  [...]

But that's begging the question.  The semantics are what you want them
to be.  Some keysigning parties take this super seriously, and maybe
with strangers there's some room for this.  But in the end, when *I*
see a key with someone else's signature on it, there is no proof how
rigorously they investigated the person.  The "reliable identity" part
of the web of trust is only one hop deep.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Henrique de Moraes Holschuh]

On Tue, 04 Oct 2011, Heiko Carstens wrote:
> > I have a question here. In case people are 'reasonably certain' that the 
> > old key has never been jeoparadized, why are they required to create a new 
> > key?

You do that when your key is either old, or weaker than the requested keys.
In the kernel.org case, if your old key is not RSA/4096...

If your old key is already RSA/4096, there are some reasons to
create a new key:

 1. "Just in case the old key was compromised", in which case you should
    revoke the old key soon.

 2. To use different keys for different purposes.

 3. To have a backup key (when proper use of subkeys is not enough to
    protect the main key) -- you better think about this carefully: how safe
    can you make the backup key storage, and _how fast_ you will notice
    should someone manage to access it?

 4. When prepararing for a key rollover in the near future (in which case
    the keys are cross-signed, and you keep collecting signatures on BOTH
    keys until the old one is decomissioned).

> > (if the old key would have been compromised, the attacker could as well 
> > generate a new key and sign it with the old key himself, so I fail to see 
> > any benefit of this PGP excercise).

Yes, he could.  The signature from the old key is used to assert that you
indeed have control of the old private key, but it cannot assert that you
are the only party that has control of the old private key.

> > It doesn't make too much sense to force people to live with two different 
> > personalities in this "PGP web of trust" world just for the sake of 
> > kernel.org, does it?
> 
> Also same question here. And as far as I can tell nobody has given an
> answer yet.

That depends, you might want to have separate keys for separate purposes
(which only makes sense if key usage will be different enough to cause
different key exposure to risks).

In any case, if you'll have different keys, it is good practice to use the
UID comment field to disclose the purpose of the key.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Wed, 05 Oct 2011 01:39:32 +0300, Adrian Bunk said:

> But the semantics of PGP key signing is that you certify that you 
> verified that a photo ID of that person matches the name on the key.

No. The semantics are that you've verified the person matches the key.
Photo ID's are *one way* of doing it.

http://www.gnupg.org/gph/en/manual.html 

The GNU Privacy Handbook says (under 'Importing a Public Key'):

"A key's fingerprint is verified with the key's owner. This may be done in
person or over the phone or through any other means as long as you can
guarantee that you are communicating with the key's true owner. If the
fingerprint you get is the same as the fingerprint the key's owner gets, then
you can be sure that you have a correct copy of the key."

Now, if you're doing a PGP keysigning, then yes, checking government-issued ID
is probably the only sane way to verify 50 or 100 people's identities in an
hour. But if you have other trustable channels of doing so, that's considerd OK
too.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Tue, 04 Oct 2011 19:17:30 EDT, "Frank Ch. Eigler" said:

> But that's begging the question.  The semantics are what you want them
> to be.  Some keysigning parties take this super seriously, and maybe
> with strangers there's some room for this.  But in the end, when *I*
> see a key with someone else's signature on it, there is no proof how
> rigorously they investigated the person.  The "reliable identity" part
> of the web of trust is only one hop deep.

And in fact, there's even support for dealing with bozos who sign keys
incorrectly:

http://www.gnupg.org/gph/en/manual.html#AEN346

"trust in a key's owner" - one of the options is:

none - The owner is known to improperly sign other keys.

(I've done that for 3 people in Europe when I found their sigs on my key on the
keyservers, and they admitted in e-mail that they'd made no real attempt to
verify me...)

You can also assign "partial" or "full" trust, and then configure how many
partial and how many full trust sigs are needed to accept a key as "known".

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Tue, Oct 04, 2011 at 07:17:30PM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Wed, Oct 05, 2011 at 01:39:32AM +0300, Adrian Bunk wrote:
> 
> > [...]  But the semantics of PGP key signing is that you certify that
> > you verified that a photo ID of that person matches the name on the
> > key.  [...]
> 
> But that's begging the question.  The semantics are what you want them
> to be.  Some keysigning parties take this super seriously, and maybe
> with strangers there's some room for this.  But in the end, when *I*
> see a key with someone else's signature on it, there is no proof how
> rigorously they investigated the person.  The "reliable identity" part
> of the web of trust is only one hop deep.

That is a rigid policy, but not the only one.

And it has practical limitations - "Key must be signed
by H. Peter Anvin" might be a consequence for kernel.org.

What policy is now used at kernel.org now is exactly the question
I asked in [1], and where I'm still waiting for an answer from hpa.

Other organizations like Debian have a clear and public policy on 
what is required for the user identification part for uploading to
the archive [2], and I expect the same for kernel.org.

> - FChE

cu
Adrian

[1] https://lkml.org/lkml/2011/10/3/362
[2] http://www.debian.org/devel/join/nm-step2

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Wed, Oct 05, 2011 at 10:54:39AM +0300, Adrian Bunk wrote:
> 
> What policy is now used at kernel.org now is exactly the question
> I asked in [1], and where I'm still waiting for an answer from hpa.
> 
> Other organizations like Debian have a clear and public policy on 
> what is required for the user identification part for uploading to
> the archive [2], and I expect the same for kernel.org.

Peter has already said "are you prepared to swear in court".
Government issued ID is one way (although any US high school student
knows how easy it is to get fake ID); personal knowledge of someone's
speach patterns plus common history generated by years of talking to
that person at conferences and/or concalls, is another way.

When I bootstrapped Linus's key, he and I talked on the phone, and I
knew him well enough by our conversation my recognizing his speach
patterns that I was prepared to certify his key even though I've never
seen his government ID.  That being said, I also know and trust Jim
Zemlin well enough to know trust that the person employed by the Linux
Foundation had his ID and right to work checked per US employment law,
and and that the person I talked to was the same person who is
employed by the Linux Foundation.  Realistically, I'm far more sure of
Linus's identity than I would be of some random Debian developer who
got his key signed after some quick impromptu verification of what
appeared to be a governement-issued ID at some conference.  :-)

						- Ted

Re: kernel.org status: establishing a PGP web of trust

[Maciej W. Rozycki]

On Tue, 4 Oct 2011, Ralf Baechle wrote:

> > Similarly anyone Cambridge UK based (or London I guess) please get in touch.
> 
> That would be me and a few more here in Cambridge.

 Sounds like a plan.

  Maciej

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Wed, Oct 05, 2011 at 01:06:16PM -0400, Ted Ts'o wrote:
> On Wed, Oct 05, 2011 at 10:54:39AM +0300, Adrian Bunk wrote:
> > 
> > What policy is now used at kernel.org now is exactly the question
> > I asked in [1], and where I'm still waiting for an answer from hpa.
> > 
> > Other organizations like Debian have a clear and public policy on 
> > what is required for the user identification part for uploading to
> > the archive [2], and I expect the same for kernel.org.
> 
> Peter has already said "are you prepared to swear in court".
> Government issued ID is one way (although any US high school student
> knows how easy it is to get fake ID); personal knowledge of someone's
> speach patterns plus common history generated by years of talking to
> that person at conferences and/or concalls, is another way.
> 
> When I bootstrapped Linus's key, he and I talked on the phone, and I
> knew him well enough by our conversation my recognizing his speach
> patterns that I was prepared to certify his key even though I've never
> seen his government ID.  That being said, I also know and trust Jim
> Zemlin well enough to know trust that the person employed by the Linux
> Foundation had his ID and right to work checked per US employment law,
> and and that the person I talked to was the same person who is
> employed by the Linux Foundation.  Realistically, I'm far more sure of
> Linus's identity than I would be of some random Debian developer who
> got his key signed after some quick impromptu verification of what
> appeared to be a governement-issued ID at some conference.  :-)

That was not what I was talking about in the email you are answering to.

Let me paraphrase my question:
"Whose signatures do I need on my key so that it will be accepted
 at kernel.org?"

With that information I can check if one email to a few local people to 
have a local keysigning is enough.

Or if I have to bother Linus to meet me and sign my key the next
time he is here in Helsinki.

> 						- Ted

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Mon, Oct 3, 2011 at 5:32 AM, Adrian Bunk <bunk@stusta.de> wrote:
> On Sun, Oct 02, 2011 at 10:53:59AM -0700, H. Peter Anvin wrote:
>> On 10/02/2011 04:54 AM, Rafael J. Wysocki wrote:
>> > On Sunday, October 02, 2011, H. Peter Anvin wrote:
>> >
>> > Hmm.  That doesn't seem very practical if someone doesn't live close
>> > to any other core kernel developers.
>> >
>>
>> You probably know enough people (including myself) that would be willing
>> to sign your key over the phone.
>>...
>
> You have personally checked Rafael's user id (e.g. passport)?
>
What about people using non-state-approved aliases for their code ?

Regards,
 - Arnaud

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Wed, Oct 05, 2011 at 10:23:49PM +0300, Adrian Bunk wrote:
> On Wed, Oct 05, 2011 at 01:06:16PM -0400, Ted Ts'o wrote:
> > On Wed, Oct 05, 2011 at 10:54:39AM +0300, Adrian Bunk wrote:
> > > 
> > > What policy is now used at kernel.org now is exactly the question
> > > I asked in [1], and where I'm still waiting for an answer from hpa.
> > > 
> > > Other organizations like Debian have a clear and public policy on 
> > > what is required for the user identification part for uploading to
> > > the archive [2], and I expect the same for kernel.org.
> > 
> > Peter has already said "are you prepared to swear in court".
> > Government issued ID is one way (although any US high school student
> > knows how easy it is to get fake ID); personal knowledge of someone's
> > speach patterns plus common history generated by years of talking to
> > that person at conferences and/or concalls, is another way.
> > 
> > When I bootstrapped Linus's key, he and I talked on the phone, and I
> > knew him well enough by our conversation my recognizing his speach
> > patterns that I was prepared to certify his key even though I've never
> > seen his government ID.  That being said, I also know and trust Jim
> > Zemlin well enough to know trust that the person employed by the Linux
> > Foundation had his ID and right to work checked per US employment law,
> > and and that the person I talked to was the same person who is
> > employed by the Linux Foundation.  Realistically, I'm far more sure of
> > Linus's identity than I would be of some random Debian developer who
> > got his key signed after some quick impromptu verification of what
> > appeared to be a governement-issued ID at some conference.  :-)
> 
> That was not what I was talking about in the email you are answering to.
> 
> Let me paraphrase my question:
> "Whose signatures do I need on my key so that it will be accepted
>  at kernel.org?"
> 
> With that information I can check if one email to a few local people to 
> have a local keysigning is enough.
> 
> Or if I have to bother Linus to meet me and sign my key the next
> time he is here in Helsinki.

Or even one step further:
Perhaps my old existing key is good enough?

- It is in the Debian emeritus keyring.
- The fingerprint is in CREDITS of the kernel since 2.6.10 in 2004.
- The fingerprint was in the context of the commit when I updated
  my CREDITS entry in 2008.
- In the unlikely case that an intruder is on my system, he will
  anyway get my new key and passphrase immediately. [1]

cu
Adrian

[1] I did check what Greg recommended in his email, but I'm not gonna 
    wipe my complete installation (including wiping /home) unless 
    someone can point at something indicating that there's a break-in
    at my machine.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Tue, Oct 4, 2011 at 6:39 PM, Adrian Bunk <bunk@stusta.de> wrote:
> On Tue, Oct 04, 2011 at 04:29:48PM -0400, Valdis.Kletnieks@vt.edu wrote:
>> On Mon, 03 Oct 2011 21:04:41 +0300, Adrian Bunk said:
>> > On Mon, Oct 03, 2011 at 12:28:17PM -0400, Frank Ch. Eigler wrote:
>>
>> > > What is the threat that this passport checking is intended to cure?
>> > > That someone else might have been impersonating Rafael for years,
>> > > sending patches, chatting in email and over the phone, and attending
>> > > conferences?
>> >
>> > Key signing is an identity check.
>>
>> That's dodging the issue. Somehow, I don't see Andrew Morton asking Linus to
>> sign his key, and Linus saying "How do I know you're the *real* Andrew Morton?"
>> And Andrew is a clever guy, if he was a fake Andrew, I'm sure he'd have gotten
>> a fake ID that would be good enough to fool Linus, who is also a clever guy but
>> I'm not aware of any special background he has in forgery detection. ;)
>>
>> The more important point is that as far as the linux-kernel community is
>> concerned, the guy we've all seen show up at conferences and present stuff all
>> these times *is* Andrew Morton, even if his real name is George Q. Smith and
>> he's been on the run for the last 27 years for an embarassing incident
>> involving an ostrich, the mayor's daughter, and 17 gallons of mineral oil in
>> the atrium of the museum. ;)
>>
>> The ID check is  to connect an actual person to the claimed key, and primarily
>> intended for key signing parties and the like, where people *don't* know each
>> other very well. I think there's something like 5 people on the linux-kernel
>> list who actually know me in real life, because I don't travel much and I'm
>> rather in the boonies.  If I asked anybody *else* who I'd not met before to
>> sign my key, yes, I'd expect them to check my ID, to ensure I wasn't somebody
>> trying to pull a fast one at the keysigning party.
>
> If you just want to be sure that patch number 100 comes from the same
> person as the 99 patches before you could do that without key signing
> (require signed patches and check that all 100 patches were signed by
>  the same key).
>
> But the semantics of PGP key signing is that you certify that you
> verified that a photo ID of that person matches the name on the key.
>
> No matter if that's needed for kernel purposes.
> And no matter if it's possible to present you a fake ID.
>
> One might discuss what requirements for access to kernel.org machines make
> sense or not, but when you sign a key you have to check a photo ID first.
>
>> > > If so, perhaps the impostor is of more value to the
>> > > project than the Real Rafael.
>> >
>> > Pseudonymous contributions to the kernel are not allowed.
>>
>> See above - whoever Andrew Morton *really* is, his contributions are hardly
>> pseudonymous.
>
> Each time a patch goes through him into the kernel, he certifies that
> his real name is Andrew Morton.
>
> If that would not be his real name, it would make him somewhere between
> completely untrustable and punishable at court.
>
Under which jurisdiction ? Under which law ?

IANAL, but US copyright law does recognize the use of pseudonym for
copyrighted work[0], without requirements to disclose one's legal
name.

 - Arnaud

[0]: http://www.copyright.gov/fls/fl101.html

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Wed, Oct 05, 2011 at 10:50:24PM +0300, Adrian Bunk wrote:
> [1] I did check what Greg recommended in his email, but I'm not gonna 
>     wipe my complete installation (including wiping /home) unless 
>     someone can point at something indicating that there's a break-in
>     at my machine.

What would you consider "proof" of a break-in on your machine that would
cause you to be willing to reinstall it?

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Wed, Oct 05, 2011 at 04:00:39PM -0400, Arnaud Lacombe wrote:
> Hi,
> 
> On Tue, Oct 4, 2011 at 6:39 PM, Adrian Bunk <bunk@stusta.de> wrote:
>...
> > Each time a patch goes through him into the kernel, he certifies that
> > his real name is Andrew Morton.
> >
> > If that would not be his real name, it would make him somewhere between
> > completely untrustable and punishable at court.
> >
> Under which jurisdiction ? Under which law ?
> 
> IANAL, but US copyright law does recognize the use of pseudonym for
> copyrighted work[0], without requirements to disclose one's legal
> name.

I am not talking about copyright law.

When you add a Signed-off-by: to a patch you have to use your real name
(see Documentation/SubmittingPatches for details).

If violating that would be considered fraud or some other crime in some 
jurisdictions is likely a non-trivial question.

>  - Arnaud
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Wed, Oct 5, 2011 at 4:19 PM, Adrian Bunk <bunk@stusta.de> wrote:
> On Wed, Oct 05, 2011 at 04:00:39PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, Oct 4, 2011 at 6:39 PM, Adrian Bunk <bunk@stusta.de> wrote:
>>...
>> > Each time a patch goes through him into the kernel, he certifies that
>> > his real name is Andrew Morton.
>> >
>> > If that would not be his real name, it would make him somewhere between
>> > completely untrustable and punishable at court.
>> >
>> Under which jurisdiction ? Under which law ?
>>
>> IANAL, but US copyright law does recognize the use of pseudonym for
>> copyrighted work[0], without requirements to disclose one's legal
>> name.
>
> I am not talking about copyright law.
>
> When you add a Signed-off-by: to a patch you have to use your real name
> (see Documentation/SubmittingPatches for details).
>
> If violating that would be considered fraud or some other crime in some
> jurisdictions is likely a non-trivial question.
>
One might still question the legality/constitutionality of such a
statement. AFAIK, Greg KH, author of the sentence (in af45f32d25c) is
not a lawyer.

Have the DCO clauses been legally validated ?

 - Arnaud

note: to avoid doubt, I am writing this mail under my legal name.

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Wed, Oct 05, 2011 at 01:09:44PM -0700, Greg KH wrote:
> On Wed, Oct 05, 2011 at 10:50:24PM +0300, Adrian Bunk wrote:
> > [1] I did check what Greg recommended in his email, but I'm not gonna 
> >     wipe my complete installation (including wiping /home) unless 
> >     someone can point at something indicating that there's a break-in
> >     at my machine.
> 
> What would you consider "proof" of a break-in on your machine that would
> cause you to be willing to reinstall it?

There is no clear definition.

Had debsums told me that /bin/bash was modified I would have been quite 
convinced.

Externally observed suspicious behavior of my machine I could not explain.

Or many other things - after all I am a person with some basic 
understanding of security and how computers work.

When I am convinced there was a break-in on my machine, I also have to 
assume that all important and not so important accounts I have anywhere 
(from unbelievably many Bugzilla accounts to machines where I have root
access) are also compromised, and have to act accordingly.

It is possible to convince me that there was likely a break-in on my 
machine, but I am not assuming the worst case automatically, and for 
going through that horror of assuming it happened I need to see 
something clearly pointing at my machine.

> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Ted Ts'o]

On Thu, Oct 06, 2011 at 12:25:26AM +0300, Adrian Bunk wrote:
> 
> Had debsums told me that /bin/bash was modified I would have been quite 
> convinced.
> 

Keep in mind that debsums is trivially easy to circument.  That just
checks against an md5 checksum stored in a text file in
/var/lib/dpkg/info/*.md5sums.  If someone modified /bin/bash it would
easy enough for them to modify the relevant md5sums file.

     	    	     	       	   	    - Ted

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Wed, Oct 05, 2011 at 04:36:50PM -0400, Arnaud Lacombe wrote:
> Hi,
> 
> On Wed, Oct 5, 2011 at 4:19 PM, Adrian Bunk <bunk@stusta.de> wrote:
> > On Wed, Oct 05, 2011 at 04:00:39PM -0400, Arnaud Lacombe wrote:
> >> Hi,
> >>
> >> On Tue, Oct 4, 2011 at 6:39 PM, Adrian Bunk <bunk@stusta.de> wrote:
> >>...
> >> > Each time a patch goes through him into the kernel, he certifies that
> >> > his real name is Andrew Morton.
> >> >
> >> > If that would not be his real name, it would make him somewhere between
> >> > completely untrustable and punishable at court.
> >> >
> >> Under which jurisdiction ? Under which law ?
> >>
> >> IANAL, but US copyright law does recognize the use of pseudonym for
> >> copyrighted work[0], without requirements to disclose one's legal
> >> name.
> >
> > I am not talking about copyright law.
> >
> > When you add a Signed-off-by: to a patch you have to use your real name
> > (see Documentation/SubmittingPatches for details).
> >
> > If violating that would be considered fraud or some other crime in some
> > jurisdictions is likely a non-trivial question.
> >
> One might still question the legality/constitutionality of such a
> statement. AFAIK, Greg KH, author of the sentence (in af45f32d25c) is
> not a lawyer.

How do you not know that such a sentance was not vetted by a lawyer?  :)

> Have the DCO clauses been legally validated ?

Lawyers were involved in it.  What do you mean by "validated"?

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[Thomas Gleixner]

On Wed, 5 Oct 2011, Adrian Bunk wrote:
> On Wed, Oct 05, 2011 at 01:06:16PM -0400, Ted Ts'o wrote:
> > On Wed, Oct 05, 2011 at 10:54:39AM +0300, Adrian Bunk wrote:
> > > 
> > > What policy is now used at kernel.org now is exactly the question
> > > I asked in [1], and where I'm still waiting for an answer from hpa.
> > > 
> > > Other organizations like Debian have a clear and public policy on 
> > > what is required for the user identification part for uploading to
> > > the archive [2], and I expect the same for kernel.org.
> > 
> > Peter has already said "are you prepared to swear in court".
> > Government issued ID is one way (although any US high school student
> > knows how easy it is to get fake ID); personal knowledge of someone's
> > speach patterns plus common history generated by years of talking to
> > that person at conferences and/or concalls, is another way.
> > 
> > When I bootstrapped Linus's key, he and I talked on the phone, and I
> > knew him well enough by our conversation my recognizing his speach
> > patterns that I was prepared to certify his key even though I've never
> > seen his government ID.  That being said, I also know and trust Jim
> > Zemlin well enough to know trust that the person employed by the Linux
> > Foundation had his ID and right to work checked per US employment law,
> > and and that the person I talked to was the same person who is
> > employed by the Linux Foundation.  Realistically, I'm far more sure of
> > Linus's identity than I would be of some random Debian developer who
> > got his key signed after some quick impromptu verification of what
> > appeared to be a governement-issued ID at some conference.  :-)
> 
> That was not what I was talking about in the email you are answering to.
> 
> Let me paraphrase my question:
> "Whose signatures do I need on my key so that it will be accepted
>  at kernel.org?"

Your understanding of key signing seems to be that some technical
measure which makes the key valid is enough to enter a web of trust.

Webs of trust cannot be built nor entered by any technical means.

A web of trust is built by personal relationships and the key signing
is just a technical measure to express that.

I really do not care about your ID card, because it's a fact that
people got keys signed by showing fake IDs.

> With that information I can check if one email to a few local people to 
> have a local keysigning is enough.

Whatfor? To regain your k.org account? Can you provide a single
reason why that should happen?

I can't think of one. You vanished away with a big bang and now you
come back out of the blue and assume that you're a trusted person just
by slapping a few signs on your key?

> Or if I have to bother Linus to meet me and sign my key the next
> time he is here in Helsinki.

And how would that change the fact that your personal trust value in
this community is exactly ZERO?

As your idea of trust seems to be based on an ID card you better find
some other place with people who are stupid enough to believe that
technical measures can replace deep personal trust.

Thanks,

	tglx

Re: kernel.org status: establishing a PGP web of trust

[Jeremy Fitzhardinge]

On 10/05/2011 04:57 PM, Thomas Gleixner wrote:
> I really do not care about your ID card, because it's a fact that
> people got keys signed by showing fake IDs.

Right, but who cares about "fake" or "real" anyway?

The point is that a given patch submitter builds up a reputation over
time.  Someone pretending to be that submitter is essentially riding on
someone else's reputation.  A web of trust and gpg signatures help
prevent this.

But having a reputation doesn't mean all your patches are good, or that
you won't suddenly turn mad or evil.  But that's not something that a
gpg signature can help with; it can only be dealt with a human
understanding of how other humans behave (and code review).

    J

Re: kernel.org status: establishing a PGP web of trust

[Chris Friesen]

On 10/05/2011 05:57 PM, Thomas Gleixner wrote:
> On Wed, 5 Oct 2011, Adrian Bunk wrote:

>> Or if I have to bother Linus to meet me and sign my key the next
>> time he is here in Helsinki.
>
> And how would that change the fact that your personal trust value in
> this community is exactly ZERO?
>
> As your idea of trust seems to be based on an ID card you better find
> some other place with people who are stupid enough to believe that
> technical measures can replace deep personal trust.

Aren't you sort of conflating personal trust with a web-of-trust?

A web-of-trust exists simply to associate a person with a key.  It *is* 
a technical measure.  If Linus is willing to assert that Adrian's key 
matches up with Adrian-as-individual, and you trust Linus, then you 
should accept Adrian's key as valid regardless of whether or not you 
personally trust him.

Chris



-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Wed, Oct 5, 2011 at 7:55 PM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Oct 05, 2011 at 04:36:50PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Wed, Oct 5, 2011 at 4:19 PM, Adrian Bunk <bunk@stusta.de> wrote:
>> > On Wed, Oct 05, 2011 at 04:00:39PM -0400, Arnaud Lacombe wrote:
>> >> Hi,
>> >>
>> >> On Tue, Oct 4, 2011 at 6:39 PM, Adrian Bunk <bunk@stusta.de> wrote:
>> >>...
>> >> > Each time a patch goes through him into the kernel, he certifies that
>> >> > his real name is Andrew Morton.
>> >> >
>> >> > If that would not be his real name, it would make him somewhere between
>> >> > completely untrustable and punishable at court.
>> >> >
>> >> Under which jurisdiction ? Under which law ?
>> >>
>> >> IANAL, but US copyright law does recognize the use of pseudonym for
>> >> copyrighted work[0], without requirements to disclose one's legal
>> >> name.
>> >
>> > I am not talking about copyright law.
>> >
>> > When you add a Signed-off-by: to a patch you have to use your real name
>> > (see Documentation/SubmittingPatches for details).
>> >
>> > If violating that would be considered fraud or some other crime in some
>> > jurisdictions is likely a non-trivial question.
>> >
>> One might still question the legality/constitutionality of such a
>> statement. AFAIK, Greg KH, author of the sentence (in af45f32d25c) is
>> not a lawyer.
>
> How do you not know that such a sentance was not vetted by a lawyer?  :)
>
I assume the worst case, unless given documents proving otherwise. The
commit message is not particularly verbose.

>> Have the DCO clauses been legally validated ?
>
> Lawyers were involved in it.  What do you mean by "validated"?
>
I would assume that to involve a court ruling, but still, I'd assume
it would need to be done by an international jurisdiction, which
AFAIK, do not exist.

I'm strongly using the conditional here as IANAL.

 - Arnaud

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Wed, Oct 5, 2011 at 8:23 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Wed, Oct 5, 2011 at 7:55 PM, Greg KH <gregkh@suse.de> wrote:
>> On Wed, Oct 05, 2011 at 04:36:50PM -0400, Arnaud Lacombe wrote:
>>> Hi,
>>>
>>> On Wed, Oct 5, 2011 at 4:19 PM, Adrian Bunk <bunk@stusta.de> wrote:
>>> > On Wed, Oct 05, 2011 at 04:00:39PM -0400, Arnaud Lacombe wrote:
>>> >> Hi,
>>> >>
>>> >> On Tue, Oct 4, 2011 at 6:39 PM, Adrian Bunk <bunk@stusta.de> wrote:
>>> >>...
>>> >> > Each time a patch goes through him into the kernel, he certifies that
>>> >> > his real name is Andrew Morton.
>>> >> >
>>> >> > If that would not be his real name, it would make him somewhere between
>>> >> > completely untrustable and punishable at court.
>>> >> >
>>> >> Under which jurisdiction ? Under which law ?
>>> >>
>>> >> IANAL, but US copyright law does recognize the use of pseudonym for
>>> >> copyrighted work[0], without requirements to disclose one's legal
>>> >> name.
>>> >
>>> > I am not talking about copyright law.
>>> >
>>> > When you add a Signed-off-by: to a patch you have to use your real name
>>> > (see Documentation/SubmittingPatches for details).
>>> >
>>> > If violating that would be considered fraud or some other crime in some
>>> > jurisdictions is likely a non-trivial question.
>>> >
>>> One might still question the legality/constitutionality of such a
>>> statement. AFAIK, Greg KH, author of the sentence (in af45f32d25c) is
>>> not a lawyer.
>>
>> How do you not know that such a sentance was not vetted by a lawyer?  :)
>>
> I assume the worst case, unless given documents proving otherwise. The
> commit message is not particularly verbose.
>
Just thinking about it, but even if lawyers have been involved, this
has been done, unless error of my part, behind closed doors, without
any public records, so I'd tempted to ask "who paid those lawyers?",
"what was the qualification of those lawyers?", "what was the interest
of those lawyers?" and "what was the interest of those who paid the
lawyers?".

Moreover, the commit message's subject states "We can not allow
anonymous contributions to the kernel", however it fails to describe
who's behind "we".

Finally, I'd be tempted to make a difference between "Anonymous" and
"Pseudonymous".

regards,
 - Arnaud

Re: kernel.org status: establishing a PGP web of trust

[John Johansen]

On 10/03/2011 09:52 PM, H. Peter Anvin wrote:
> On 10/03/2011 09:49 PM, Ted Ts'o wrote:
>>
>> Note that if your laptop allows incoming ssh connections, and you
>> logged into master.kernel.org with ssh forwarding enabled, your laptop
>> may not be safe.  So be very, very careful before you assume that your
>> laptop is safe.  At least one kernel developer, after he got past the
>> belief, "surely I could have never had my machine be compromised",
>> looked carefully and found rootkits on his machines.
>>
>>        		     	   	       - Ted
> 
> By the way, I'm now pretty convinced that allowing inbound ssh on
> laptops (which is the default on all the mainline Linux distros as far
> as I know) is seriously broken... laptops get connected to *extremely*
> insecure networks on just way too regular a basis.
> 
I can't speak for the other distros but Ubuntu does not enable sshd by
default.  The openssh-server package or ssh meta package must be
installed before sshd will be run.

Re: kernel.org status: establishing a PGP web of trust

[hpanvin@gmail.com]

Good.

John Johansen <john.johansen@canonical.com> wrote:

>On 10/03/2011 09:52 PM, H. Peter Anvin wrote:
>> On 10/03/2011 09:49 PM, Ted Ts'o wrote:
>>>
>>> Note that if your laptop allows incoming ssh connections, and you
>>> logged into master.kernel.org with ssh forwarding enabled, your
>laptop
>>> may not be safe.  So be very, very careful before you assume that
>your
>>> laptop is safe.  At least one kernel developer, after he got past
>the
>>> belief, "surely I could have never had my machine be compromised",
>>> looked carefully and found rootkits on his machines.
>>>
>>>        		     	   	       - Ted
>> 
>> By the way, I'm now pretty convinced that allowing inbound ssh on
>> laptops (which is the default on all the mainline Linux distros as
>far
>> as I know) is seriously broken... laptops get connected to
>*extremely*
>> insecure networks on just way too regular a basis.
>> 
>I can't speak for the other distros but Ubuntu does not enable sshd by
>default.  The openssh-server package or ssh meta package must be
>installed before sshd will be run.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Wed, Oct 05, 2011 at 08:50:08PM -0400, Arnaud Lacombe wrote:
> On Wed, Oct 5, 2011 at 8:23 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> > I assume the worst case, unless given documents proving otherwise. The
> > commit message is not particularly verbose.
> >
> Just thinking about it, but even if lawyers have been involved, this
> has been done, unless error of my part, behind closed doors, without
> any public records, so I'd tempted to ask "who paid those lawyers?",
> "what was the qualification of those lawyers?", "what was the interest
> of those lawyers?" and "what was the interest of those who paid the
> lawyers?".
> 
> Moreover, the commit message's subject states "We can not allow
> anonymous contributions to the kernel", however it fails to describe
> who's behind "we".

*plonk*

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Wed, Oct 05, 2011 at 07:47:16PM -0400, Ted Ts'o wrote:
> On Thu, Oct 06, 2011 at 12:25:26AM +0300, Adrian Bunk wrote:
> > 
> > Had debsums told me that /bin/bash was modified I would have been quite 
> > convinced.
> 
> Keep in mind that debsums is trivially easy to circument.  That just
> checks against an md5 checksum stored in a text file in
> /var/lib/dpkg/info/*.md5sums.  If someone modified /bin/bash it would
> easy enough for them to modify the relevant md5sums file.

I am not so naïve to assume there was any way to prove my machine is not 
compromised.

My first assumption is that my machine is not compromised, and also
that the latest e2fsprogs you uploaded to Debian unstable and that
I installed on my machine does not contain a trojan added by someone
who hijacked your machine or your key.

There is no 100% security, only compromises between security and costs.

>      	    	     	       	   	    - Ted

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Thomas Gleixner]

On Wed, 5 Oct 2011, Chris Friesen wrote:

> On 10/05/2011 05:57 PM, Thomas Gleixner wrote:
> > On Wed, 5 Oct 2011, Adrian Bunk wrote:
> 
> > > Or if I have to bother Linus to meet me and sign my key the next
> > > time he is here in Helsinki.
> > 
> > And how would that change the fact that your personal trust value in
> > this community is exactly ZERO?
> > 
> > As your idea of trust seems to be based on an ID card you better find
> > some other place with people who are stupid enough to believe that
> > technical measures can replace deep personal trust.
> 
> Aren't you sort of conflating personal trust with a web-of-trust?

No, I'm fighting the idiocy that people seem to believe that a web of
signed keys has any value other than technically establishing the
identity of a person.

> A web-of-trust exists simply to associate a person with a key.  It *is* a
> technical measure.  If Linus is willing to assert that Adrian's key matches up
> with Adrian-as-individual, and you trust Linus, then you should accept
> Adrian's key as valid regardless of whether or not you personally trust him.

If Linus signs his key, then all it means is that I can be sure to a
certain degree that the person who is using the key is Adrian. But
it's neither a free ticket for a k.org account nor does it have any
other meaning.

Thanks,

	tglx

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Thu, Oct 06, 2011 at 01:57:24AM +0200, Thomas Gleixner wrote:
> On Wed, 5 Oct 2011, Adrian Bunk wrote:
>...
> > Let me paraphrase my question:
> > "Whose signatures do I need on my key so that it will be accepted
> >  at kernel.org?"
>
> Your understanding of key signing seems to be that some technical
> measure which makes the key valid is enough to enter a web of trust.
>
> Webs of trust cannot be built nor entered by any technical means.
>
> A web of trust is built by personal relationships and the key signing
> is just a technical measure to express that.
>
> I really do not care about your ID card, because it's a fact that
> people got keys signed by showing fake IDs.
>
> > With that information I can check if one email to a few local people to 
> > have a local keysigning is enough.
> 
> Whatfor? To regain your k.org account? Can you provide a single
> reason why that should happen?
> 
> I can't think of one. You vanished away with a big bang and now you
> come back out of the blue and assume that you're a trusted person just
> by slapping a few signs on your key?

I would say I vanished silently after several big bangs with you and 
other people and some other incidents, but that's not really relevant.

My main reason for regaining my kernel.org account is that I heavily 
used my bunk@kernel.org address for kernel development (just check the 
kernel history), and I was still getting emails to that.

Assuming the @kernel.org addresses will not vanish, I need accepted 
credential for accessing that address.

> > Or if I have to bother Linus to meet me and sign my key the next
> > time he is here in Helsinki.
> 
> And how would that change the fact that your personal trust value in
> this community is exactly ZERO?

Your trust in me is exactly zero, and that wouldn't change if you'd sign 
my key.

And for some other people in this community the same is surely also true.

Now I can laugh about the incident when a member of the program commitee 
(sic) of a kernel summit sent me an angry "Why didn't you take your seat?"
email - it turned out I was not invited.

I don't know anything about the behind-the-scenes politics of kernel 
development, but I got the message that some people want to avoid my
physical presence, and will not impose that on anyone who does not
want to meet me. [1]

> As your idea of trust seems to be based on an ID card you better find
> some other place with people who are stupid enough to believe that
> technical measures can replace deep personal trust.

We are talking about the technical requirements for regaining an 
account I was trusted to have before.

If anyone accepts patches from me, or if Linus will ever again pull git 
trees from me, are questions completely unrelated to whether you or he 
or anyone else signs my key.

> Thanks,
> 
> 	tglx

cu
Adrian

[1] And my "have to bother Linus to meet me" was intended as asking him
    if it would be possible, I wouldn't do stalking if he'd refuse.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Alan Cox]

> When you add a Signed-off-by: to a patch you have to use your real name

Don't confuse real name and legal name. In particular remember

- Not all countries have a notion of legal name
- In many places 'real' and legal names are not particularly tied together
- Both legal and real names change but there is no kernel facility to
  update existing sign offs.
- Some cultures have multiple names for people as the norm
- A lot of signed off entries are transliterated (We don't have many
  signed off in Japanese or Chinese for example but mostly in
  transliterated form)
- The "official" transliterations vary by country, and no specific
  transliteration or indeed specific language is necessarily correct
- In many cases it is possible to change your "real" name to a nickname,
  (and indeed back again). Genuine UK names for official purposes include
  people like Mr Telephone Booth (changed his name for charity and kept
  it), and "Fruitbat".

So can I suggest we leave that quagmire for Google+ to sink into and
flounder and stay well out of it.

A key merely proves that the person who signed the object had access to
the key. A signed key merely proves that someone or indeed something with
access to the relevant key data signed it. Even in person signing proves
surprisingly little.  (Ob amusement - can one of a pair of identical
twins ever become a Debian developer)

It's an administrative convenience.

Signing patches is also only useful for tracing probable origin. It
doesn't prove they are any good. That's one reason I never signed any
security announcement when I was the CERT contact, it forced people to
check the announcement and advice made sense.

Alan

Re: kernel.org status: establishing a PGP web of trust

[Thomas Gleixner]

On Thu, 6 Oct 2011, Adrian Bunk wrote:
> On Thu, Oct 06, 2011 at 01:57:24AM +0200, Thomas Gleixner wrote:
> > Whatfor? To regain your k.org account? Can you provide a single
> > reason why that should happen?
> > 
> > I can't think of one. You vanished away with a big bang and now you
> > come back out of the blue and assume that you're a trusted person just
> > by slapping a few signs on your key?
> 
> I would say I vanished silently after several big bangs with you and 
> other people and some other incidents, but that's not really relevant.
> 
> My main reason for regaining my kernel.org account is that I heavily 
> used my bunk@kernel.org address for kernel development (just check the 
> kernel history), and I was still getting emails to that.
> 
> Assuming the @kernel.org addresses will not vanish, I need accepted 
> credential for accessing that address.

You seem to believe that the fact that you had a @k.org address is
enough of a reason that it will be restored?

> > As your idea of trust seems to be based on an ID card you better find
> > some other place with people who are stupid enough to believe that
> > technical measures can replace deep personal trust.
> 
> We are talking about the technical requirements for regaining an 
> account I was trusted to have before.

As you might have noticed, the rules under which those accounts are
given out have been changed and the change is not only a question of
providing a signed gpg key.

Thanks,

	tglx

Re: kernel.org status: establishing a PGP web of trust

[Josh Boyer]

On Thu, Oct 6, 2011 at 4:04 AM, Adrian Bunk <bunk@stusta.de> wrote:
> My main reason for regaining my kernel.org account is that I heavily
> used my bunk@kernel.org address for kernel development (just check the
> kernel history), and I was still getting emails to that.
>
> Assuming the @kernel.org addresses will not vanish, I need accepted
> credential for accessing that address.

As I understand things, the @kernel.org addresses will simply forward
to somewhere else from now on.  There will be no active email hosting
on kernel.org.

josh

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Thu, Oct 06, 2011 at 12:22:01PM +0200, Thomas Gleixner wrote:
> On Thu, 6 Oct 2011, Adrian Bunk wrote:
> > On Thu, Oct 06, 2011 at 01:57:24AM +0200, Thomas Gleixner wrote:
> > > Whatfor? To regain your k.org account? Can you provide a single
> > > reason why that should happen?
> > > 
> > > I can't think of one. You vanished away with a big bang and now you
> > > come back out of the blue and assume that you're a trusted person just
> > > by slapping a few signs on your key?
> > 
> > I would say I vanished silently after several big bangs with you and 
> > other people and some other incidents, but that's not really relevant.
> > 
> > My main reason for regaining my kernel.org account is that I heavily 
> > used my bunk@kernel.org address for kernel development (just check the 
> > kernel history), and I was still getting emails to that.
> > 
> > Assuming the @kernel.org addresses will not vanish, I need accepted 
> > credential for accessing that address.
> 
> You seem to believe that the fact that you had a @k.org address is
> enough of a reason that it will be restored?

I used it as the permanent address for kernel work, and there are 1011
"Signed-off-by: Adrian Bunk <bunk@kernel.org>" lines in the kernel log.

If anyone wants to contact me regarding anything I did in the kernel 
that is the address.

I did not use it for any non-kernel stuff, and will not use it for that 
in the future.

You were asking for a single reason why I want to regain my kernel.org 
account, and this is the reason.

>...
> Thanks,
> 
> 	tglx

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kernel.org status: establishing a PGP web of trust

[Adrian Bunk]

On Thu, Oct 06, 2011 at 07:05:01AM -0400, Josh Boyer wrote:
> On Thu, Oct 6, 2011 at 4:04 AM, Adrian Bunk <bunk@stusta.de> wrote:
> > My main reason for regaining my kernel.org account is that I heavily
> > used my bunk@kernel.org address for kernel development (just check the
> > kernel history), and I was still getting emails to that.
> >
> > Assuming the @kernel.org addresses will not vanish, I need accepted
> > credential for accessing that address.
> 
> As I understand things, the @kernel.org addresses will simply forward
> to somewhere else from now on.  There will be no active email hosting
> on kernel.org.

With the level of security now imposed I surely won't be allowed to set 
or change the address where emails are forwarded to without a trusted 
key.

> josh

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Cambridge, UK key signing meeting. Thursday 13th Oct

[Jonathan Cameron]

Date: Thursday 13th Oct.

Location: Cambridge University Engineering Department, Trumpington Street

Time: Either 2pm or 7pm.  Please say which time/s you can make.

Attending so far:
Ralf Baechle
Jonathan Cameron

I might be able to get a few parking spaces if people give me plenty of warning.

Please circulate to anyone who might be interested.

email jic23@cam.ac.uk if you plan to attend so I can make sure we have a big enough room.
I might also need to give names to security if we go with the 7pm option.

I'll send out details and directions to those who are coming nearer the time.

Jonathan Cameron

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Wed, 05 Oct 2011 20:50:08 EDT, Arnaud Lacombe said:

> Just thinking about it, but even if lawyers have been involved, this
> has been done, unless error of my part, behind closed doors, without
> any public records, so I'd tempted to ask "who paid those lawyers?",
> "what was the qualification of those lawyers?", "what was the interest
> of those lawyers?" and "what was the interest of those who paid the
> lawyers?".

At least in the US, the answer to "what was the interest of those lawyers?" is
almost always "to represent the interests of their clients in a legally ethical
manner".  Intentional disregard for the client's interests can and does get you
disbarred.  Any lawyer who stuck in a clause that was contrary to the client's
interest would also be doing so against their own interest - lawyers can get
sued for malpractice or (as noted) even disbarrment.  So I don't think you need
to worry about some lawyer with a pro-Microsoft agenda secretly sticking in a
hidden phrase that's actually against Linux's interest. (In particular, it's
*really* hard to hide detrimental language in something as short and heavily
read as the Developer's Certificate of Origin).

And if you *do* worry about that, you better also question whether the
people supplying tin foil are part of the conspiracy too.

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Thu, Oct 6, 2011 at 9:44 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Wed, 05 Oct 2011 20:50:08 EDT, Arnaud Lacombe said:
>
>> Just thinking about it, but even if lawyers have been involved, this
>> has been done, unless error of my part, behind closed doors, without
>> any public records, so I'd tempted to ask "who paid those lawyers?",
>> "what was the qualification of those lawyers?", "what was the interest
>> of those lawyers?" and "what was the interest of those who paid the
>> lawyers?".
>
> At least in the US, the answer to "what was the interest of those lawyers?" is
> almost always "to represent the interests of their clients in a legally ethical
> manner".  Intentional disregard for the client's interests can and does get you
> disbarred.  Any lawyer who stuck in a clause that was contrary to the client's
> interest would also be doing so against their own interest - lawyers can get
> sued for malpractice or (as noted) even disbarrment.  So I don't think you need
> to worry about some lawyer with a pro-Microsoft agenda secretly sticking in a
> hidden phrase that's actually against Linux's interest. (In particular, it's
> *really* hard to hide detrimental language in something as short and heavily
> read as the Developer's Certificate of Origin).
>
> And if you *do* worry about that, you better also question whether the
> people supplying tin foil are part of the conspiracy too.
>
I do not particularly worry about any of the question I wrote, I was
merely raising unknown, from some excerpt of
http://www.groklaw.net/articlebasic.php?story=20101227144336645.

 - Arnaud

Re: kernel.org status: establishing a PGP web of trust

[Jon Masters]

On Tue, 2011-10-04 at 16:29 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 03 Oct 2011 21:04:41 +0300, Adrian Bunk said:
> > On Mon, Oct 03, 2011 at 12:28:17PM -0400, Frank Ch. Eigler wrote:
> 
> > > What is the threat that this passport checking is intended to cure?
> > > That someone else might have been impersonating Rafael for years,
> > > sending patches, chatting in email and over the phone, and attending
> > > conferences?
> >
> > Key signing is an identity check.
> 
> That's dodging the issue. Somehow, I don't see Andrew Morton asking Linus to
> sign his key, and Linus saying "How do I know you're the *real* Andrew Morton?"
> And Andrew is a clever guy, if he was a fake Andrew, I'm sure he'd have gotten
> a fake ID that would be good enough to fool Linus, who is also a clever guy but
> I'm not aware of any special background he has in forgery detection. ;)

Exactly. This is why we really need to get over the stupidity of turning
up to keysigning parties and looking at passports from countries we've
never been to as if we could really even tell they weren't freshly
printed. I know I wouldn't know what a Russian passport is supposed to
look like, even though I've seen many apparently from that country.

What I'd like to see is "keysigning" parties where folks with well
established (in use) keys turn up and *prove* they own the key by
signing some information the other attendees provide. That way they can
not only say "hey, I'm dude X, trust me this is my fingerprint, here's a
photo ID" (which means nothing in the case of a well established online
identify that is trusted already), but they can say "hey, I have access
to this key, because I just signed that random message you gave me
interactively". Who cares who the heck they really are beyond that?
(intentionally a loaded statement to make the point).

Jon.

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Adrian Bunk <bunk@stusta.de> writes:

> If you just want to be sure that patch number 100 comes from the same
> person as the 99 patches before you could do that without key signing
> (require signed patches and check that all 100 patches were signed by
>  the same key).

This leaves room for MITM attacks. The attacked can remove the original
signature and add his own.
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Thu, 06 Oct 2011 09:30:47 +0200, Thomas Gleixner said:

> If Linus signs his key, then all it means is that I can be sure to a
> certain degree that the person who is using the key is Adrian. But
> it's neither a free ticket for a k.org account nor does it have any
> other meaning.

Exactly.  It proves it's Adrian. What you *do* with that information is
an entirely different question.

Many people manage to conflate "authentication" and "authorization",
which are two entirely different things in the security world.  My favorite
example demonstrating the difference:

Authentication: "Yes, your driver's license does say you're Jeffrey Dahmer".
Authorization: "Would you like to borrow a steak knife, Jeffrey?"

(For the non-US people - Dahmer was a notorious serial killer and cannibal:
https://secure.wikimedia.org/wikipedia/en/wiki/Jeffrey_Dahmer

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Mark Brown]

On Thu, Oct 06, 2011 at 11:58:22AM -0400, Jon Masters wrote:

> What I'd like to see is "keysigning" parties where folks with well
> established (in use) keys turn up and *prove* they own the key by
> signing some information the other attendees provide. That way they can
> not only say "hey, I'm dude X, trust me this is my fingerprint, here's a
> photo ID" (which means nothing in the case of a well established online
> identify that is trusted already), but they can say "hey, I have access
> to this key, because I just signed that random message you gave me
> interactively". Who cares who the heck they really are beyond that?
> (intentionally a loaded statement to make the point).

A common approach to this for at least the e-mail portion of the address
is to sign the ID with the address and then mail the signed key
encrypted to the address, deleting all local copies and requiring that
the recipient publish the signature.  This at least demonstrates that
the owner of the key can read mail at that address.

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> A common approach to this for at least the e-mail portion of the address
> is to sign the ID with the address and then mail the signed key
> encrypted to the address, deleting all local copies and requiring that
> the recipient publish the signature.  This at least demonstrates that
> the owner of the key can read mail at that address.

The assumption here is the attacker can read (and write) victim's email.
It's not about verifying email access or address.
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Thu, Oct 06, 2011 at 06:39:40PM +0100, Mark Brown wrote:
> On Thu, Oct 06, 2011 at 11:58:22AM -0400, Jon Masters wrote:
> 
> > What I'd like to see is "keysigning" parties where folks with well
> > established (in use) keys turn up and *prove* they own the key by
> > signing some information the other attendees provide. That way they can
> > not only say "hey, I'm dude X, trust me this is my fingerprint, here's a
> > photo ID" (which means nothing in the case of a well established online
> > identify that is trusted already), but they can say "hey, I have access
> > to this key, because I just signed that random message you gave me
> > interactively". Who cares who the heck they really are beyond that?
> > (intentionally a loaded statement to make the point).
> 
> A common approach to this for at least the e-mail portion of the address
> is to sign the ID with the address and then mail the signed key
> encrypted to the address, deleting all local copies and requiring that
> the recipient publish the signature.  This at least demonstrates that
> the owner of the key can read mail at that address.

The 'caff' tool does this for you automatically.  I just learned of it
yesterday, and already it's saved me loads of time.  Highly recommended,
and odds are it's already packaged up for you in your distro.

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[Mark Brown]

On Thu, Oct 06, 2011 at 07:45:45PM +0200, Krzysztof Halasa wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> > A common approach to this for at least the e-mail portion of the address
> > is to sign the ID with the address and then mail the signed key
> > encrypted to the address, deleting all local copies and requiring that
> > the recipient publish the signature.  This at least demonstrates that
> > the owner of the key can read mail at that address.

> The assumption here is the attacker can read (and write) victim's email.
> It's not about verifying email access or address.

Bear in mind that this is only done after a successful out of band
verification - it's purely about verifying the e-mail portion of the
identity which the person has already asserted that they control.

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/06/2011 10:48 AM, Greg KH wrote:
> 
> The 'caff' tool does this for you automatically.  I just learned of it
> yesterday, and already it's saved me loads of time.  Highly recommended,
> and odds are it's already packaged up for you in your distro.
> 

I have to say that I personally find it extremely annoying that it
requires an extra email step.  Annoying enough that this tool was the
main reason I stop going to key signings in the past.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/06/2011 11:08 AM, H. Peter Anvin wrote:
> On 10/06/2011 10:48 AM, Greg KH wrote:
>>
>> The 'caff' tool does this for you automatically.  I just learned of it
>> yesterday, and already it's saved me loads of time.  Highly recommended,
>> and odds are it's already packaged up for you in your distro.
>>
> 
> I have to say that I personally find it extremely annoying that it
> requires an extra email step.  Annoying enough that this tool was the
> main reason I stop going to key signings in the past.
> 

(Although to be fair I must say Enigmail makes it a lot less obnoxious.)

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Hi Peter,

> 5. Get as many other kernel developers that you have physical access to
>    to sign your key after verifying the fingerprint.  Verifying keys
>    over the phone is OK if and only if you know them *extremely* well;
>    think "would I be willing to testify in court that the person I
>    talked to was X"?

Do you have, by chance, a list of developers whom I can contact to have
the new key signed? Unfortunately I'm seldom outside Poland (and Warsaw
spefically), so I'd prefer local people. Something (using the right key
ring etc.) like

	gpg2 --list-keys '.pl>'

should work for a start I think.
Any other idea perhaps?

TIA.
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Thursday, October 06, 2011, Krzysztof Halasa wrote:
> Hi Peter,
> 
> > 5. Get as many other kernel developers that you have physical access to
> >    to sign your key after verifying the fingerprint.  Verifying keys
> >    over the phone is OK if and only if you know them *extremely* well;
> >    think "would I be willing to testify in court that the person I
> >    talked to was X"?
> 
> Do you have, by chance, a list of developers whom I can contact to have
> the new key signed? Unfortunately I'm seldom outside Poland (and Warsaw
> spefically), so I'd prefer local people. Something (using the right key
> ring etc.) like
> 
> 	gpg2 --list-keys '.pl>'
> 
> should work for a start I think.
> Any other idea perhaps?

I'm based in Warsaw if that helps.

Thanks,
Rafael

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Thu, 06 Oct 2011 11:58:22 EDT, Jon Masters said:

> What I'd like to see is "keysigning" parties where folks with well
> established (in use) keys turn up and *prove* they own the key by
> signing some information the other attendees provide. That way they can
> not only say "hey, I'm dude X, trust me this is my fingerprint, here's a
> photo ID" (which means nothing in the case of a well established online
> identify that is trusted already), but they can say "hey, I have access
> to this key, because I just signed that random message you gave me
> interactively". 

Wouldn't the fact that I attend the keysigning party and claim that I was
the owner of key B4D3D7B0, and then subsequently signing your key with
that same key, prove that I actually controlled key B4D3D7B0?

The other possibility is that I was an impostor *and* that the real owner of
key B4D3D7B0 was coincidentally going around that same day and signing keys for
everybody at the keysigning without doing proper verification.  Which you have
to admit is rather a long shot...


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [Warsaw Poland] kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> I'm based in Warsaw if that helps.

Great then. I was under impression you are presently in UK - must have
had someone else in mind.

So, how about some "piwko", weekend maybe? I'm also free on Friday,
though perhaps someone else is interested?

Thanks Peter.
-- 
Krzysztof Halasa

Re: [Warsaw Poland] kernel.org status: establishing a PGP web of trust

[Rafael J. Wysocki]

On Thursday, October 06, 2011, Krzysztof Halasa wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > I'm based in Warsaw if that helps.
> 
> Great then. I was under impression you are presently in UK - must have
> had someone else in mind.
> 
> So, how about some "piwko", weekend maybe? I'm also free on Friday,
> though perhaps someone else is interested?

Well, I'd prefer Friday.

Thanks,
Rafael

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

> On Thu, 06 Oct 2011 11:58:22 EDT, Jon Masters said:
>> What I'd like to see is "keysigning" parties where folks with well
>> established (in use) keys turn up and *prove* they own the key by
>> signing some information the other attendees provide. That way they can
>> not only say "hey, I'm dude X, trust me this is my fingerprint, here's a
>> photo ID" (which means nothing in the case of a well established online
>> identify that is trusted already),

The person may be trusted but how do you know the message apparently
from that person is genuine?

Valdis.Kletnieks@vt.edu writes:

> Wouldn't the fact that I attend the keysigning party and claim that I was
> the owner of key B4D3D7B0, and then subsequently signing your key with
> that same key, prove that I actually controlled key B4D3D7B0?

I don't think it's needed. Alice claims ownership of key B4D3D7B0, gets
signatures on B4D3D7B0 public key. Bob (who actually controls B4D3D7B0)
reads Alice's mail and signs something "in Alice's name". Alice loses.
There are many ways for Alice to lose if she wishes to. One of the
simpler ones is to send the private key straight to Chuck then erase it
from her computer.

It's Alice's problem to make sure other people sign her key instead of
some other number she has found on the floor. It's their responsibility
to verify Alice's identity, but they aren't responsible for her actions.
-- 
Krzysztof Halasa

Re: kernel.org status: hints on how to check your machine for intrusion

[Andrea Arcangeli]

On Fri, Sep 30, 2011 at 04:59:24PM -0700, Greg KH wrote:
>    If you have a source-based system (Gentoo, LFS, etc.) you presumably
>    know what you are doing already.

Gentoo portage updates through mirrors by default are insecure and I'm
not sure everyone knows what's doing already considering it's not the
default and if I talk to people they're not aware about it. So I
thought it's appropriate to send a reminder considering your topic...

To be secure if you use Gentoo you need to add webrsync-gpg to
FEATURES in make.conf and then use only emerge-webrsync (and never use
emerge --sync). Then you should be safe, after that the
SHA1/SHA256/RMD160 of every further download is verified against the
Manifests which have been cryptographically signed. It's very naive
and too insecure to trust any random mirror and emerge --sync should
be abolished and webrsync-gpg should be the default in FEATURES. After
you see "Good signature from" in output from emerge-webrsync you
should be safe. tarsync then speed things up.

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Fri, 07 Oct 2011 00:16:01 +0200, Krzysztof Halasa said:

> > Wouldn't the fact that I attend the keysigning party and claim that I was
> > the owner of key B4D3D7B0, and then subsequently signing your key with
> > that same key, prove that I actually controlled key B4D3D7B0?
> 
> I don't think it's needed. Alice claims ownership of key B4D3D7B0, gets
> signatures on B4D3D7B0 public key. Bob (who actually controls B4D3D7B0)
> reads Alice's mail and signs something "in Alice's name". Alice loses.

You got that 180 degrees out of phase.  Jon said he wanted a keysigning party
where I would prove that I own key B4D3D7B0 (which is, in fact, my key) by
signing something random. My claim is that if I can take Jon's key and sign it
with B4D3D7B0, that's already proving I control the key, and another signing
of something else doesn't prove anything regarding my control of the key.

Now mind you, it *does* have its uses - for example, "sign the random string
I just e-mailed you" will verify that I have control of the e-mail address that the
key claims to be attached to.  But that's different from proving I have control
of the actual key.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Greg KH]

On Fri, Oct 07, 2011 at 12:29:14PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Oct 2011 00:16:01 +0200, Krzysztof Halasa said:
> 
> > > Wouldn't the fact that I attend the keysigning party and claim that I was
> > > the owner of key B4D3D7B0, and then subsequently signing your key with
> > > that same key, prove that I actually controlled key B4D3D7B0?
> > 
> > I don't think it's needed. Alice claims ownership of key B4D3D7B0, gets
> > signatures on B4D3D7B0 public key. Bob (who actually controls B4D3D7B0)
> > reads Alice's mail and signs something "in Alice's name". Alice loses.
> 
> You got that 180 degrees out of phase.  Jon said he wanted a keysigning party
> where I would prove that I own key B4D3D7B0 (which is, in fact, my key) by
> signing something random. My claim is that if I can take Jon's key and sign it
> with B4D3D7B0, that's already proving I control the key, and another signing
> of something else doesn't prove anything regarding my control of the key.
> 
> Now mind you, it *does* have its uses - for example, "sign the random string
> I just e-mailed you" will verify that I have control of the e-mail address that the
> key claims to be attached to.  But that's different from proving I have control
> of the actual key.

If you are worried about this type of thing, then just use the tool
'caff' when signing keys, it handles all of this type of thing
automatically as well as making it very easy to sign keys.  I just found
it a few days ago and it's already saved me tons of time.

greg k-h

Re: kernel.org status: establishing a PGP web of trust

[Arnaud Lacombe]

Hi,

On Fri, Oct 7, 2011 at 12:29 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Fri, 07 Oct 2011 00:16:01 +0200, Krzysztof Halasa said:
>
>> > Wouldn't the fact that I attend the keysigning party and claim that I was
>> > the owner of key B4D3D7B0, and then subsequently signing your key with
>> > that same key, prove that I actually controlled key B4D3D7B0?
>>
>> I don't think it's needed. Alice claims ownership of key B4D3D7B0, gets
>> signatures on B4D3D7B0 public key. Bob (who actually controls B4D3D7B0)
>> reads Alice's mail and signs something "in Alice's name". Alice loses.
>
> You got that 180 degrees out of phase.  Jon said he wanted a keysigning party
> where I would prove that I own key B4D3D7B0 (which is, in fact, my key) by
> signing something random. My claim is that if I can take Jon's key and sign it
> with B4D3D7B0, that's already proving I control the key, and another signing
> of something else doesn't prove anything regarding my control of the key.
>
> Now mind you, it *does* have its uses - for example, "sign the random string
> I just e-mailed you" will verify that I have control of the e-mail address that the
> key claims to be attached to.  But that's different from proving I have control
> of the actual key.
>
How so ? The public key BOb has is mathematically tied to the private
key Alice has. If Bob sends Alice a mail, and then, she send a reply
signed with her key, which is tied to the mail address used by Bob.
Then, Bob successfully verifies the signature. This proves Alice has
control over the key tied and the mail address, don't it ? Alice
cannot successfully sign the mail without both having control over the
key and the mail address.

 - Arnaud

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Fri, 07 Oct 2011 12:59:30 EDT, Arnaud Lacombe said:

> How so ? The public key BOb has is mathematically tied to the private
> key Alice has. If Bob sends Alice a mail, and then, she send a reply
> signed with her key, which is tied to the mail address used by Bob.
> Then, Bob successfully verifies the signature. This proves Alice has
> control over the key tied and the mail address, don't it ? 

As I said - yes, that *DOES* prove control over key and email address.

The point is that signing something random does not prove anything about
control of the *KEY ONLY* that isn't also proved by using the key to sign
another key.


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Jon Masters]

On Fri, 2011-10-07 at 12:29 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Oct 2011 00:16:01 +0200, Krzysztof Halasa said:
> 
> > > Wouldn't the fact that I attend the keysigning party and claim that I was
> > > the owner of key B4D3D7B0, and then subsequently signing your key with
> > > that same key, prove that I actually controlled key B4D3D7B0?
> > 
> > I don't think it's needed. Alice claims ownership of key B4D3D7B0, gets
> > signatures on B4D3D7B0 public key. Bob (who actually controls B4D3D7B0)
> > reads Alice's mail and signs something "in Alice's name". Alice loses.
> 
> You got that 180 degrees out of phase.  Jon said he wanted a keysigning party
> where I would prove that I own key B4D3D7B0 (which is, in fact, my key) by
> signing something random. My claim is that if I can take Jon's key and sign it
> with B4D3D7B0, that's already proving I control the key, and another signing
> of something else doesn't prove anything regarding my control of the key.

What I'm saying is that unless you sign something (random text, my
actual key(s)) in my presence, I can't actually know it was you I was
dealing with or someone else claiming to be you (or your identity).

I see all these keysigning parties where people dutifully check IDs they
don't really know how to recognize and am always struck by how the
offline post-event nature effectively never proves the person you met in
real life is the person whose key you just signed, just that some ID
seemed to reasonably match the name on the fingerprint at the time. I
bet it someone turned up at one of these events with a $100 fake ID made
in China of the kind I hear about on the radio these days, a large
majority of those present would happily sign a key claiming to match
that ID after the event, even if the real owner was never there.

Jon.

Re: kernel.org status: establishing a PGP web of trust

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On Sat, 08 Oct 2011 01:02:13 EDT, Jon Masters said:

> What I'm saying is that unless you sign something (random text, my
> actual key(s)) in my presence, I can't actually know it was you I was
> dealing with or someone else claiming to be you (or your identity).

Now see, this is *exacltly* why security people have to be pedantic about
stuff.  What you originally asked for was "sign random data to demonstrate
control of the key", and I pointed out that being able to sign a key was as
good as being able to sign random data to prove control of the key.

However, it now turns out that your *actual* worry is "binding the person
who controls the key with the person who controls the e-mail", which is
in fact a valid concern for some situations, and as pointed out, requires
a bit more effort to establish.

However, you have to remember that *all* real-life identity proofs are to
some degree probabalistic.  How do you know your lawyer is a *real* lawyer
and not somebody with a fake degree?  Mostly because the other lawers
in town and the judges are convinced he's a lawyer too.  Same goes for
your doctor - how do you know he *really* went to med school?  Even calling
the med school and verifying only proves that somebody with that name went
there that year.  And yes, every year we hear about a few fake lawyers and
doctors on the news.  But society seems to muddle along just fine anyhow.

(Incidentally, something most people don't realize is that the entire debit/credit
card industry is *designed* with the assumption that between 2 and 4
percent of all transactions will turn out to be fraudulent in some way.  So
everybody keeps a small buffer for chargebacks and life goes on).

Similarly for PGP -  it's not *that* hard to create a totally new e-mail
account, a new name, get a fake ID, go to a few key signings, and have a nice
validated bogus PGP ID.  However, do we really *care* in that case?  Probably
not.  What we *care* more about is somebody creating a fake ID in somebody
else's name.  And that turns out to be rather self-limiting - all it takes is
*one* person to send the real person an e-mail that says "Glad to meet you at
the keysigining last week", and the ruse is revealed when the real person
realizes he wasn't *at* the keysigning.

And even if the identities *are* perfectly confirmed, that doesn't remove all
the risk.  You can have somebody you've known for years, do background checks,
and be 100% convinced he's the real person.  But if you then use PGP to encrypt
the secret plans for the revolution and e-mail it to him, PGP says nothing at
all about whether he's in reality a government mole who's infiltrated your
orgainization...

That's why nobody worries too much about the "is it really him?" side - the
world is full enough of properly identified but duplicious people to worry
about the few who have fake identities and are duplicious. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Valdis.Kletnieks@vt.edu writes:

> You got that 180 degrees out of phase.  Jon said he wanted a keysigning party
> where I would prove that I own key B4D3D7B0 (which is, in fact, my key) by
> signing something random.

But this is not needed at all. While signing someone's public key, you
don't need to check if he has a corresponding private key. That's BTW
the same as with PKI certificate requests.

By signing one's public key you don't certify at all that you know
anything about the corresponding private key. You certify that the
person in question confirmed this public key belongs to him/her. You may
want to check the email part, but it's part of the identity check, not
the private key check.

The check if someone has access to the private key is important later,
when we can't see the person.

> My claim is that if I can take Jon's key and sign it
> with B4D3D7B0, that's already proving I control the key, and another signing
> of something else doesn't prove anything regarding my control of the
> key.

That may be disputable but what I wanted to say is it simply doesn't
matter.

> Now mind you, it *does* have its uses - for example, "sign the random string
> I just e-mailed you" will verify that I have control of the e-mail address that the
> key claims to be attached to.  But that's different from proving I have control
> of the actual key.

Definitely.
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[Geert Uytterhoeven]

On Sat, Oct 8, 2011 at 16:36, <Valdis.Kletnieks@vt.edu> wrote:
> However, you have to remember that *all* real-life identity proofs are to
> some degree probabalistic.  How do you know your lawyer is a *real* lawyer
> and not somebody with a fake degree?  Mostly because the other lawers
> in town and the judges are convinced he's a lawyer too.  Same goes for
> your doctor - how do you know he *really* went to med school?  Even calling
> the med school and verifying only proves that somebody with that name went
> there that year.  And yes, every year we hear about a few fake lawyers and
> doctors on the news.  But society seems to muddle along just fine anyhow.

In real life, it's also called the web of trust. How do you prove to a foreign
government that you're (a) not a convicted criminal and (b) in a healthy state?
  - You ask your doctor to write a signed declaration,
  - You go to the ministry of healthcare, which checks the signature
and registration
    number of the doctor, and adds a signature and stamp to the document,
  - You go to the police station, to get a good standing certificate, signed by
    the mayor,
  - You go to the ministry of foreign affairs, which checks the
signatures and stamps
    of the ministry of healthcare officer and of the mayor, and adds
an apostille
    to your documents,
  - The foreign government verifies the apostille from your ministry of foreign
    affairs.

Very similar to PGP ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Jon Masters <jonathan@jonmasters.org> writes:

> What I'm saying is that unless you sign something (random text, my
> actual key(s)) in my presence, I can't actually know it was you I was
> dealing with or someone else claiming to be you (or your identity).

Ahh, that's when the key is already signed, and when you can't see the
person in question. Sure. That's a normal ID check using the asymmetric
key pair.

> I see all these keysigning parties where people dutifully check IDs they
> don't really know how to recognize and am always struck by how the
> offline post-event nature effectively never proves the person you met in
> real life is the person whose key you just signed, just that some ID
> seemed to reasonably match the name on the fingerprint at the time.

There is nothing post-event in it. You are to collect (or check) the
fingerprint and check the ID. Post-event you only check the fingerprint
(against the authenticated fingerprint you collected at the party).
Assuming the fingerprint algorithm is secure (i.e. it's reasonably hard
to produce a collision) this process is safe.

> I
> bet it someone turned up at one of these events with a $100 fake ID made
> in China of the kind I hear about on the radio these days, a large
> majority of those present would happily sign a key claiming to match
> that ID after the event, even if the real owner was never there.

Yes. The signing party only proves a connection between a
reasonably-looking ID (and/or person) and a private key. It's very hard
to go any further, what would you use? A full genome check versus one's
parents? :-)

Of course it's much harder to impersonate someone who is well known.
That's also why a big international key signing party isn't the best
idea.
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Valdis.Kletnieks@vt.edu writes:

> Same goes for
> your doctor - how do you know he *really* went to med school?  Even calling
> the med school and verifying only proves that somebody with that name went
> there that year.

Actually, it's only proves that the person on the other end says his
name is at the time in the files. You wanted to be pedantic :-)
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[Jon Masters]

On Sat, 2011-10-08 at 10:36 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sat, 08 Oct 2011 01:02:13 EDT, Jon Masters said:
> 
> > What I'm saying is that unless you sign something (random text, my
> > actual key(s)) in my presence, I can't actually know it was you I was
> > dealing with or someone else claiming to be you (or your identity).
> 
> Now see, this is *exacltly* why security people have to be pedantic about
> stuff.  What you originally asked for was "sign random data to demonstrate
> control of the key", and I pointed out that being able to sign a key was as
> good as being able to sign random data to prove control of the key.

Good point about being pedantic, and the rest of your comments :) I
understand that I'm taking this a little far but I'm just trying to
point out one particular gaping hole in the way these things are
currently done. One reason I stopped doing keysigning parties is that I
realized they were mostly a show. You turn up and get a key signed and
then everyone is impressed that you're in the strong set...wupdedoo. Not
that I've anything against signing stuff on kernel.org and trying to
improve things (I've long directly signed everything on master with my
own keys in slight violation of policy, but that turned out to right).

:)

Jon.

Re: kernel.org status: establishing a PGP web of trust

[Krzysztof Halasa]

Jon Masters <jonathan@jonmasters.org> writes:

> One reason I stopped doing keysigning parties is that I
> realized they were mostly a show. You turn up and get a key signed and
> then everyone is impressed that you're in the strong set...wupdedoo.

I think there are other weaknesses than those. Examples:
- people checking the fingerprints on the keyserver, then getting the
  keys later and signing without checking the fingerprints again (the
  fingerprint may "change"),
- people sending the public key through email etc., and signing the key
  without checking (the key may change in email).

Especially in a situation like this one, when a key signing activity is
expected, people MUST check the fingerprint against the authenticated
one WHILE signing the key. It's probably more important that the very
careful check of ID authenticity (watermarks etc).

I'd be only a little surprised if some key signing fraud resulting in
kernel.org access attempt or something similar is detected soon.

> Not
> that I've anything against signing stuff on kernel.org and trying to
> improve things (I've long directly signed everything on master with my
> own keys in slight violation of policy, but that turned out to right).

At first I thought you meant signing with your private key on master :-)
-- 
Krzysztof Halasa

Re: kernel.org status: establishing a PGP web of trust

[H. Peter Anvin]

On 10/08/2011 10:59 AM, Jon Masters wrote:
>
> Good point about being pedantic, and the rest of your comments :) I
> understand that I'm taking this a little far but I'm just trying to
> point out one particular gaping hole in the way these things are
> currently done. One reason I stopped doing keysigning parties is that I
> realized they were mostly a show. You turn up and get a key signed and
> then everyone is impressed that you're in the strong set...wupdedoo. Not
> that I've anything against signing stuff on kernel.org and trying to
> improve things (I've long directly signed everything on master with my
> own keys in slight violation of policy, but that turned out to right).
>

Not so much in violation of policy... we just couldn't get people to do it.

	-hpa

Re: kernel.org status: establishing a PGP web of trust

[Jon Masters]

On Sat, 2011-10-08 at 14:09 -0700, H. Peter Anvin wrote:
> On 10/08/2011 10:59 AM, Jon Masters wrote:

> > Good point about being pedantic, and the rest of your comments :) I
> > understand that I'm taking this a little far but I'm just trying to
> > point out one particular gaping hole in the way these things are
> > currently done. One reason I stopped doing keysigning parties is that I
> > realized they were mostly a show. You turn up and get a key signed and
> > then everyone is impressed that you're in the strong set...wupdedoo. Not
> > that I've anything against signing stuff on kernel.org and trying to
> > improve things (I've long directly signed everything on master with my
> > own keys in slight violation of policy, but that turned out to right).
> >
> 
> Not so much in violation of policy... we just couldn't get people to do it.

Right, no offense to you intended, and I know you tried :) I suspect
that won't be a huge problem now...or I hope so.

Jon.

Re: kernel.org status: hints on how to check your machine for intrusion

[Andrew Watts]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Sun, Oct 02, 2011 at 07:03:52AM -0500, Andy wrote:
> Many of us would benefit from having signatures for some of the recent
> kernels missing for your list as well as Willy's.

Using my cloned repo, I calculated SHA-256 fingerprints missing in Greg's
list as well as MD5 hashes missing from Willy's. I hope this helps anyone
looking for those.

~ Andy

[-- Attachment #2: sha256.txt --]
[-- Type: text/plain, Size: 7971 bytes --]

sha256 signatures (002 umask 1st; 022 umask 2nd)

linux-2.6.34.tar:
746539e5c1d3dbcadb19e73e05979f6276dba00d87f8cc94fe82b82210c61b28  -
40f42fd33258644ec494330295e4a340df3542813e1bdd6c531a4a4c9e66133d  -
linux-2.6.34.1.tar:
8274ebf7c748bc7a9099a62462cd9c5f4120f1517c9ff8343d3d5ff0a5512d89  -
fd15431e3f51ecaede55e9e7dc4ba9ff2987487583e498e11876a92dafee384c  -
linux-2.6.34.2.tar:
25c1235599261c76cfe2053fd55b8a9c75d523fee0ca79169d5c161c1107161e  -
8d44af7f2c6fc44bf9780031a96f25cd28eb038d6b78170bfca39494ca02c92f  -
linux-2.6.34.3.tar:
244c36077e3a1cb915a0754fa673e978d307e0670e1a4ea7ad2e705cdc61acf5  -
ac38ad5e643731696b5e7a075646be2cc7b10c39f6aec692995b2369357d3c38  -
linux-2.6.34.4.tar:
ac55c475b60d99d9a05361fb2552a0d93e031aae9fdf7b69035d3a0118a44dc3  -
10e822934027be2864cbcb32cb2b28d499bd4292f662191022004dd64de27197  -
linux-2.6.34.5.tar:
d70bf85124b6b3932cb19e33db670022f33ceb0d397abf4117d159f427ee7a88  -
6bb6bc698e94858f5dbc0faca0e2eb618b4c53fe03d40a9e9a72e281b3b712c2  -
linux-2.6.34.6.tar:
439d7db6e1f391ce5d3af2027cc4a9fc7638eef9e61c6d362652d226a17574ac  -
66a0b5bec97200e6138ef0967c6474edd127785c6df4e65fcbf7a53ab6a6f7f6  -
linux-2.6.34.7.tar:
c0811c096978f48f42685798b23d855cc2a7f2c601d6fcc05559953614f4eb3d  -
e4a939cb69a0f175309096c0c2afb72f62981d273b182b0caae6068f90ae653a  -
linux-2.6.35.tar:
f13307a6fb4f93e40fbd172ccbe7fb19e7b98cb78ef354a79469881efd7e14ce  -
395327db2c94a53dfa52b19e94f7c2a9085fced016920b964870455af269c45c  -
linux-2.6.35.1.tar:
04f938f049eb60910842a4c2295747c9973c6ee452d76a0d09c977fe22912065  -
26b42925d5c22af72c8d318b97aa47347701fde2a52c069a701a0bd0481cb1ae  -
linux-2.6.35.2.tar:
197cf215b307ebe7f03f9d1b6d79c8c0a907837d1fd96c6eab0d48108959e319  -
42e217d51849f624d3513caee99ebff8b42d87d40cecbce020e53235dbeb9a5f  -
linux-2.6.35.3.tar:
95f5705c096d33f59e4a5fd51f06ad5ee16aee43ac6bdc50efcd30c9322e8dcb  -
ca2889ac26c95654544bb87f00ebf994f37ad81495cfa7c8caab4064c6c5e6e1  -
linux-2.6.35.4.tar:
490049b2bf2a68d11d3e85fb1f45a6bccaab151d7fb40227b173b03be2667bd3  -
a70c10a471d239f36be6f05f41d82fa9a6c2611778a9e935dce0027a06cf87ac  -
linux-2.6.35.5.tar:
7a508628ff425e363ba7a8b8fb909bc4c6f481cee0ff06ee04b7df1384b07f44  -
3790c7415ddd3091999f0a14e4ec886e47097afe89116895a01c7cb92d3d21be  -
linux-2.6.35.6.tar:
14436d1c3c1b43703878f0c7b1487ed544d6a9957dd95cc8ca12e7c878da268a  -
74d33a25a3f209fbf6106f147a8e2d821e2468e4e0eb439fcd2efc531966eb37  -
linux-2.6.35.7.tar:
fc756e1352dfb753bb55ec1ef5ad04b7667fbf4e65968b1cf0347e54f4039c82  -
c44706d8f9a13796c9d57afcb99bc7eea8d5aaa8aa6d0e2262302ec2c0b602c0  -
linux-2.6.35.8.tar:
3c8898822eb71c9e9392a10eec6dea9ca07a3b3ba168b0568a4dd509f5ce2e39  -
386ba52ad2d01d48df200b9bf6f6a709690533374c26debfe643e1fae874f2ee  -
linux-2.6.35.9.tar:
d9bbf8bec6becba1bff6cac20f736c6939d5bd9f011ea9aa9e6eacde82903337  -
6a60d66cfd1f38feafdb1c6c65793bc449dc46afb163813d1b675a30344babc3  -
linux-2.6.36.tar:
2d6564d3985956c4a7a5c5b71d581577eacba0db7221057aff72fe9545a50a5f  -
8f732856612fdb7785f9337ed7e196ab54e01f7d816a7a1ff8cd155e4fb1d24f  -
linux-2.6.36.1.tar:
94d383796b8d958f85ae5e35458d42c782efc4aa72720f49d3beeff1b5e184c4  -
ec336e16bc916a59bf434adb2aef0049c8e0b47f42824f25227e3e8b10f90988  -
linux-2.6.36.2.tar:
7b209cea4f1606c87fee18ba536f3b14a33b8e25604a750520ce7d719c024a1d  -
57da6fad51edc7a936aa22c26230ab082cdc4cb60f040736561eb6990a15e0af  -
linux-2.6.36.3.tar:
45f390f4b70a277db4513dfeb8ea7ce3fdef0ebd7d74e5170512d1fc7d486ec5  -
582c5ab09ccbf472b2ef0cb817b7f429f940bdc69eb45e95d8e9e481cb546e63  -
linux-2.6.36.4.tar:
c6bcc922b5ccd16ee5645edf9137bb51bf352a86b35dc7970acc7d16b31dac80  -
d1ea7dba02894b0bf9b6edd5655586aae4775703e80f0f0aca86dcf4e2f766d4  -
linux-2.6.37.tar:
0f006f4b1fd94c3397cc1cee64028415ba0b4865395de3ccced6e105efd4daba  -
5a97390b9acfd05bf79bcc6aba42b5c64019ab8cf1fe5bd00d5b6ae4cca461ce  -
linux-2.6.37.1.tar:
305afde1da22f35dd05ebd2216a5e62dd2e5b2897675b3b89075a4b0e5d5582e  -
9be49c4110c06056c1a9a17afe32b140767b18d9eb771dc383988af163b4f307  -
linux-2.6.37.2.tar:
a5c3dab13ec52594758574295faf54967692181f801cbcd1710f704e66c83a20  -
dbf1f345ca961f4f1c4db325fb8567149e934ef8eb9bdf65c0b128565ec63796  -
linux-2.6.37.3.tar:
b7e5a1490e1d08fcef84d59a2b89c7252ce9d87e55365901f6cef26b31f8749e  -
3d0a4b1d552b4aa791a0873e2f546e88faaed5e891f736081cfa4bc9cdadb1ee  -
linux-2.6.37.4.tar:
6e10e657000ba4a764695267bdecb6f7132994f2ab3dbd6ec931c6e64259b1b7  -
b97d7a98000437ebc38db857e00ebfdeb1b622833e137acf36fcc8dbea70fe7f  -
linux-2.6.37.5.tar:
c3f37501503a5198ed7e198387dd74293ad9a3330bd3dba507fda05e439605df  -
12c6bcc43643f35b600d543f9143d123f564e6a6393eb06797c86b50e90d89ff  -
linux-2.6.37.6.tar:
913b7028e50263036c5392d57a8aaeadf965b6ff79951a720f655031c86f5c31  -
69abe8c4773b46e15470e47b7268fab707a506cf706ed0330068a60cee6e9fca  -
linux-2.6.38.tar:
8ae53dda91dc6824f168d979f9e7b123e4ca7661648a959c45df25ff35d3cb19  -
c34c34959285170c1d9e260f29beedcfa4b7b63a462d7c3c4c01f02f8695d01f  -
linux-2.6.38.1.tar:
aafb2189068de36ca7a4add4beebf5d2dd1c0577f2590857d7e9aa0882d74445  -
8bda7a79f80428444ee7cf84df2087c724fc091074b8e229a18fbe45b296657e  -
linux-2.6.38.2.tar:
bec1a58ad95c9227d2e6127e29dfe8f880b500ac67130d377d3d2d2443ff8798  -
d85978d9c92eec7ebbcb2841852d54a914df7d2d4c0e1a771826ef0634d6ef67  -
linux-2.6.38.3.tar:
611167c44347a25fb433a1060b7041b53561f4c2ec211877eeba62b5bb01e458  -
1974e9522704ca57c2be2ca66807e182b5344dea6840f2564203fe75b0ae12c5  -
linux-2.6.38.4.tar:
85485b7efff3a3d928e0ba6dc653d984bd33642179002ca43c390b473cbaffa6  -
f9ad9a2f13b7c7518323881907a895ead28e4680464120c9f086188dc8569232  -
linux-2.6.38.5.tar:
cfa874a79cc402ca7674dd5f28d556ccdfe6ad7f004fdf48f2e4dd50ae2a1f17  -
944bfb3c61fe9f4d8c5163f1baee3f43c5e5a56e90e8ba1b5beaf4dd1085eaff  -
linux-2.6.38.6.tar:
70b677bcce2ef1c8d51d533896ce1e4f2959d04c9cde74e3ee3a326e7bf87f37  -
9001e4859dee32a5aedbb37c4ffc430d452a2dbb0c5f90298b8f6965ea35106d  -
linux-2.6.38.7.tar:
4a9b98df4640ed4ffd04c14e12771cdd49d1f418620ea1dd5d6d3764ae7fb30c  -
de5960e33a6205aa069fec21843196891fce990300674a9bb763a618c1952a5d  -
linux-2.6.38.8.tar:
a4700aa87275357b38c296d029d1fc4f27dee7a21ffa1e2d2e0f180dcebd1fe2  -
29106de74533d1ab2515cb8c26324819a248d4920bd35bd31ab52e45a552c03d  -
linux-2.6.39.tar:
67d7ebc2e9a7687ac73046bf71984d499eda2700f65e56456cee59e7644e0bfc  -
5b301f400d80cf806ee5eb3f66a8c8c1baa46411f78e70db314434dd608068e1  -
linux-2.6.39.1.tar:
b25f63091ef909968c27fdb1299767341009525b9dbf0cec9b21dcaee86be7a6  -
d0ef598dddaaa0148a6cfd17894ec60e284074914bf0e5fadbf89328183c5667  -
linux-2.6.39.2.tar:
a05107d04f02c7c350f1cd03d6fc9b98be879231afe145b476888c4512bdec10  -
2347cca6028c5f3e0e74980c36ef0a6e0593ca44be894f60834ca138e4626a14  -
linux-2.6.39.3.tar:
cc98dcf11c6658ac7a2551e9d73145fff019809b2a5e61da71c8d12612e74ef9  -
19ada681ff4dc157fab70db7c14a0ffc91b459b52615ad1dbf5aab52698c43cb  -
linux-2.6.39.4.tar:
c21b1191f84bd6640ef2a3d615828cee9efbf1cec78bff0305f753af9a3553c5  -
8d2bb638a634f41d1cf95cc3ba16fecd54665ad50709629a8a25abafcbd39b82  -
linux-3.0.tar:
7f7498f6fe78474b986ee2fd617e4def35041547b2d6f5fd6b347dac592e399c  -
de25a96079d037fbf4b4b74f237af18d878d2354d3fdd3c79048a2269474416b  -
linux-3.0.1.tar:
5296531e3dbf7bf55573a2f400403061340eec801ecbaade9793791827bd5b1f  -
62a609a5c66b2e6fcb32204d812ae211554b9a07630c9ec78660f3682d6da529  -
linux-3.0.2.tar:
d2c0636033bbfc6722e71b566cdc95265cf10af300ff2c3f8fba9ab7ec63b725  -
595062c115c7369a2659c06189080f8b079a09bdd1bd447ccbde05f1a8f6289e  -
linux-3.0.3.tar:
92769e812e8fc83b226e97d5732d2a0eb96e598f096b4f10085b0352be7492e1  -
e5e75e47cb5ba91d980aab00c85a9f3e9f8faf0c59c4d5f5dd732555a5f88943  -
linux-3.0.4.tar:
ca42bbbffb6db60f16a7870bc1f3ddc872596d9ef1bc4794377ed1da101f14f9  -
4d8856b2c0608568450774f4d475aba6581ca693ac92d070a0d376753e75a630  -
linux-3.0.5.tar:
47ecb8193563dcb5b051f289d6d3a4098dbd0083dd7ad57b519654d0c151b732  -
9314db9104355bcfd0ec7d340dbc20252e2d9536b4ec8edc9b7c34ee22ebc4ee  -
linux-3.0.6.tar:
2705e2b904da860e23e00961952904642308b82c1467c2c54bec61d2460a0ef4  -
6106c59ca1ca08cf2a356254d828342e9fd06b9ec4f680200ce489a9ad15f541  -

[-- Attachment #3: md5.txt --]
[-- Type: text/plain, Size: 4547 bytes --]

md5 signatures (002 umask 1st; 022 umask 2nd)

linux-2.6.33.6.tar:
c0c49ff442a9a38bf19b54981c396477  -
b3faaa2f8230135d00625379980bc435  -
linux-2.6.33.7.tar:
f954231ecad72c06ef7564d46406e44f  -
737d3cb01e24c1d6bd5c99932f43e897  -
linux-2.6.33.8.tar:
495e5af33b256ff056accf8650986be3  -
1b2b9b198ae88e854b550690b627bb2d  -
linux-2.6.33.9.tar:
faab2b03eff6543c8bf63101309b61b4  -
6a2431cb305ea2ab01312240db27c72a  -
linux-2.6.33.10.tar:
d0466173fe28142b1079041d35e3d326  -
edfc7315e1d85c033cb4edb387bc0772  -
linux-2.6.33.11.tar:
bd13cd19cf5ad42a027db60a557ac27b  -
e13cb054a8fb85c0cce51e4f6fe2e18d  -
linux-2.6.33.12.tar:
cfb4eeb135b2f872d782b51511c039a5  -
454b3b4f0f62635203a969f3ce242569  -
linux-2.6.33.13.tar:
f577df3c53a265e4a76aeecbd563d332  -
4fbe59625fe81889b4d24be49aded371  -
linux-2.6.33.14.tar:
7805feff0bf8a657d16c5881459f1add  -
b0383fa9c7010ae48c9602c926d71251  -
linux-2.6.33.15.tar:
a807da8ad93204739e739ddcd06afdd4  -
135404e9a0a777284d2d8a0e1877c6c3  -
linux-2.6.33.16.tar:
7c7d462611cd35e979e3ff2408765bf4  -
ef47ddc41a0c861182c57b4d9383aaed  -
linux-2.6.33.17.tar:
9a3f51532f5f753de84145b1bc8dde2f  -
9d095e954d5c80e7e58e3a30f8426417  -
linux-2.6.33.18.tar:
5d5666fc2b7b070de62dc9b581ee2c14  -
3db7751bcd4963c142b25ad8227d9f31  -
linux-2.6.33.19.tar:
4f7c313f0ec36aa080bea2a29d267978  -
dc96354a8431dc1e95c4e70dd484f267  -
linux-2.6.34.1.tar:
b5ab09577bac71665b0a6afc01aa8991  -
c7915e10a51aef83ad07ab1310dfea1f  -
linux-2.6.34.2.tar:
a51d818279e0402e0f9810f1a81896a4  -
214422b2c37496a587ede9c3d8b4267e  -
linux-2.6.34.3.tar:
4171780e929adb9bcf845894d4b34772  -
58a0dbd6691ef31cd7755d4d78deb5c3  -
linux-2.6.34.4.tar:
13f3eb829305c9662a7c61808cd78f5e  -
7c36973983f382c10c7fa798afca34bd  -
linux-2.6.34.5.tar:
b52ed8d879f462f80b4171874e345ce2  -
0342e66778f34ee3dafe429ceb0bc458  -
linux-2.6.34.6.tar:
6ff1290538fc568f5c5dec8be92e7304  -
44db4c923a52e8bcbfd28e9e47a1646a  -
linux-2.6.34.7.tar:
20d960afa5c81924595bb631aeb25bfe  -
468570633260e25c0892ca6ed60932e6  -
linux-2.6.36.1.tar:
44944e1bf4bbe6be6c9b19caabd2e46a  -
5287acb01a7294edf9126e06b31cddf8  -
linux-2.6.36.2.tar:
8b6557c4f0cef60b1c0cfd389ac76c81  -
8a89ddf731cf3e6cc74a0f705c4e64f7  -
linux-2.6.36.3.tar:
ac4a519bd303d1552bdf2ef28cea9400  -
e7fdd2863fd43e661c6d42d827cff83f  -
linux-2.6.36.4.tar:
eb84076b4f2ffbe6ec397db09c4b76c0  -
875cc534c1988451f56133c7cd21067f  -
linux-2.6.37.1.tar:
a358b14b41133571d8d006c1799c748c  -
9dca1bc83eeb2d8f6441f0850b93d66c  -
linux-2.6.37.2.tar:
42865250767ded55861ae0cc569f4cdf  -
06377a030705b5858ab0dd2df81763e6  -
linux-2.6.37.3.tar:
4cefa352f70a1f5b61f91a7ffcfe4f5b  -
a7aa93bb57ae7d70da9ccf8cfa13d68d  -
linux-2.6.37.4.tar:
1faea970049f982abd1f735c0eaf5200  -
59e8f872873dad91116a0da48ae148c2  -
linux-2.6.37.5.tar:
918d912d411ecafe07c4c536a192a860  -
ffe1f317e1f1009d02c198507f2107f2  -
linux-2.6.37.6.tar:
8c5acdd2de588e03cf788f51ba49fd52  -
8c145547c9d99611effcd439f53f5e25  -
linux-2.6.38.1.tar:
7e61835baf0e180582e7899a53333d36  -
654ff6ff832e1a94abcfc76e16fc43ff  -
linux-2.6.38.2.tar:
28b115c1e5ef3311d83449ca55eb1e93  -
99a6b2563f1da07024b558b45acbdd92  -
linux-2.6.38.3.tar:
7241f0ed5fdb946958ae07839dc37fc4  -
1b6aab7b43d47c53330689886180ac7c  -
linux-2.6.38.4.tar:
7e79df0e18344fb38a5222df07124ba2  -
2030ad771359131c8274084fea616e79  -
linux-2.6.38.5.tar:
c334701518dee7a785f24d10b684287e  -
e3428c253ed44718140f7252f01b6354  -
linux-2.6.38.6.tar:
f78b06daf92715dba4f5524eda2db4c2  -
a48346b83898859aa09d87ae0a06c764  -
linux-2.6.38.7.tar:
d8ae75de84c9c8a80b3ae3628550dbe1  -
ff0300eeb87975a6122fc4855754acd5  -
linux-2.6.38.8.tar:
9f98099e7e89e6eacfefcde48c72c459  -
33547d248cae58e362b33b50d464ccf3  -
linux-2.6.39.1.tar:
3ec312d569811554efce499b8f5f655d  -
91d1831f891b6cc0be3e7974d12a3e16  -
linux-2.6.39.2.tar:
6d5d0821f9febfcba8ce652872240b80  -
4e7fe20c7dec40235e54d18ff9f06f75  -
linux-2.6.39.3.tar:
1b9fdd3b3ce19eec99e5c22d54c466f9  -
af224f04deb77224d0793310a2a88ee9  -
linux-2.6.39.4.tar:
829d4bd2e2d2f91b8ae36f52b6f38836  -
d0a992d3c779c3ed5285d6cafa72d63b  -
linux-3.0.1.tar:
900437c6d0bd7dd788280d2b4c6cee69  -
aca86780981a9ea5445c38a8aafbc2b4  -
linux-3.0.2.tar:
c498c8f9e6a9348876126145bd280a20  -
e07a9dd94710799f160edc526ee75d37  -
linux-3.0.3.tar:
ec951f7427b62b51b09f1861563e1917  -
f0e79c23dcc7552b3eb6ba64cd4ab8b3  -
linux-3.0.4.tar:
c3b5d549d03db5597396b48f08a52aec  -
2542acc5e08e581ebf4d61e0e1ab5430  -
linux-3.0.5.tar:
e34805baaf276d4d6490d94d818962f5  -
ea08e9d7cf650d29ea376d40f985ea77  -
linux-3.0.6.tar:
0c30f5ee57067a0d598d68d0e218b393  -
cf075e7f519a3b9498d676869d599d3e  -

Re: Cambridge, UK key signing meeting. Thursday 13th Oct

[Jonathan Cameron]

On 10/06/11 14:27, Jonathan Cameron wrote:
> Date: Thursday 13th Oct.
> 
> Location: Cambridge University Engineering Department, Trumpington Street
> 
> Time: Either 2pm or 7pm.  Please say which time/s you can make.
> 
> Attending so far:
> Ralf Baechle
> Jonathan Cameron
> 
> I might be able to get a few parking spaces if people give me plenty of warning.
> 
> Please circulate to anyone who might be interested.
> 
> email jic23@cam.ac.uk if you plan to attend so I can make sure we have a big enough room.
> I might also need to give names to security if we go with the 7pm option.
> 
> I'll send out details and directions to those who are coming nearer the time.
> 
> Jonathan Cameron

I've just sent out an email to those who have replied so far.  If I missed someone
or anyone else wants to come it is at 2pm, Thurs 15th.  Email me for more details.

Jonathan

Re kernel.org status: hints on how to check your machine for intrusion

[Matthew W.S. Bell]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Fri, 30 Sep 2011 16:59:24 -0700, Greg KH wrote: 
> 2. Verify that your package signatures match what your package manager thinks
>    they are.

<snip>

> To do this on a Debian based system, run the following bash snippet:
> 	dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n;
> 	fi; done > ~/tmp.txt
> 	for f in `cat ~/tmp.txt`; do debsums -s -a $f; done

At least since squeeze, debsums defaults to checking all packages, so
the following is sufficient:
	debsums -as

It may also be worth checking the output of:
	debsums --list-missing

Matthew W.S. Bell

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re kernel.org status: hints on how to check your machine for intrusion

[Matthew W.S. Bell]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Fri, 30 Sep 2011 16:59:24 -0700, Greg KH wrote: 
> 2. Verify that your package signatures match what your package manager thinks
>    they are.

<snip>

> To do this on a Debian based system, run the following bash snippet:
> 	dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n;
> 	fi; done > ~/tmp.txt
> 	for f in `cat ~/tmp.txt`; do debsums -s -a $f; done

At least since squeeze, debsums defaults to checking all packages, so
the following is sufficient:
	debsums -as

It may also be worth checking the output of:
	debsums --list-missing

Matthew W.S. Bell

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: kernel.org status: hints on how to check your machine for intrusion

[Jean Delvare]

Hi Greg,

Yes I know I'm late, sorry about that.

On Fri, 30 Sep 2011 16:59:24 -0700, Greg KH wrote:
>    b. Strange directories in /usr/share that do not belong to a package.
>       This can be checked on an rpm system with the following bash snippet:
> 	for file in `find /usr/share/`; do
> 		package=`rpm -qf -- ${file} | grep "is not owned"`
> 		if [ -n "$package" ] ; then
> 			echo "weird file ${file}, please check this out"
> 		fi
> 	done

FWIW, the above doesn't work in the general case. For one thing it
fails for files which have a space in their name. But a bigger problem
is that rpm is localized so for any user running a non-English locale,
the grep "is not owned" will not catch anything (in addition to being
slow.) Better just check the value returned by rpm:

find /usr/share -print0 \
| while read -d $'\0' -r file
do
	if ! rpm -qf --quiet -- "${file}" ; then
		if [ -L "${file}" ] ; then
			type=link
		elif [ -d "${file}" ] ; then
			type=directory
		else
			type=file
		fi

		echo "Weird ${type} ${file}, please check this out"
	fi
done

Even with this, I'm not convinced, due to the high number of false
positives (generated cache files, directories not explicitly packaged,
etc...) it is hard to make sense of the output. We'd need to fix all
the packages first so that only actual changes are returned by the
script.

I'm also unsure why /usr/share would be a better target than any other
system directory.

-- 
Jean Delvare

Re: kernel.org status: hints on how to check your machine for intrusion

[Greg KH]

On Tue, Oct 18, 2011 at 05:13:49PM +0200, Jean Delvare wrote:
> Hi Greg,
> 
> Yes I know I'm late, sorry about that.
> 
> On Fri, 30 Sep 2011 16:59:24 -0700, Greg KH wrote:
> >    b. Strange directories in /usr/share that do not belong to a package.
> >       This can be checked on an rpm system with the following bash snippet:
> > 	for file in `find /usr/share/`; do
> > 		package=`rpm -qf -- ${file} | grep "is not owned"`
> > 		if [ -n "$package" ] ; then
> > 			echo "weird file ${file}, please check this out"
> > 		fi
> > 	done
> 
> FWIW, the above doesn't work in the general case. For one thing it
> fails for files which have a space in their name. But a bigger problem
> is that rpm is localized so for any user running a non-English locale,
> the grep "is not owned" will not catch anything (in addition to being
> slow.) Better just check the value returned by rpm:
> 
> find /usr/share -print0 \
> | while read -d $'\0' -r file
> do
> 	if ! rpm -qf --quiet -- "${file}" ; then
> 		if [ -L "${file}" ] ; then
> 			type=link
> 		elif [ -d "${file}" ] ; then
> 			type=directory
> 		else
> 			type=file
> 		fi
> 
> 		echo "Weird ${type} ${file}, please check this out"
> 	fi
> done

Thanks for the updated script, you are right, it was localized for my
system.

> Even with this, I'm not convinced, due to the high number of false
> positives (generated cache files, directories not explicitly packaged,
> etc...) it is hard to make sense of the output.

Really?  I see almost none of that on my openSUSE boxes.

> We'd need to fix all
> the packages first so that only actual changes are returned by the
> script.
> 
> I'm also unsure why /usr/share would be a better target than any other
> system directory.

It's a very common place for rootkits to hide their files.

And they look pretty obvious when you see them, so they will not just
blend in with the other "normal" files you describe above.  So it's
still a good thing to run to check your system to help ensure that it is
clean.

thanks,

greg k-h

Re: kernel.org status: hints on how to check your machine for intrusion

[Jean Delvare]

On Tue, 18 Oct 2011 08:21:33 -0700, Greg KH wrote:
> On Tue, Oct 18, 2011 at 05:13:49PM +0200, Jean Delvare wrote:
> > Hi Greg,
> > 
> > Yes I know I'm late, sorry about that.
> > 
> > On Fri, 30 Sep 2011 16:59:24 -0700, Greg KH wrote:
> > >    b. Strange directories in /usr/share that do not belong to a package.
> > >       This can be checked on an rpm system with the following bash snippet:
> > > 	for file in `find /usr/share/`; do
> > > 		package=`rpm -qf -- ${file} | grep "is not owned"`
> > > 		if [ -n "$package" ] ; then
> > > 			echo "weird file ${file}, please check this out"
> > > 		fi
> > > 	done
> > 
> > FWIW, the above doesn't work in the general case. For one thing it
> > fails for files which have a space in their name. But a bigger problem
> > is that rpm is localized so for any user running a non-English locale,
> > the grep "is not owned" will not catch anything (in addition to being
> > slow.) Better just check the value returned by rpm:
> > 
> > find /usr/share -print0 \
> > | while read -d $'\0' -r file
> > do
> > 	if ! rpm -qf --quiet -- "${file}" ; then
> > 		if [ -L "${file}" ] ; then
> > 			type=link
> > 		elif [ -d "${file}" ] ; then
> > 			type=directory
> > 		else
> > 			type=file
> > 		fi
> > 
> > 		echo "Weird ${type} ${file}, please check this out"
> > 	fi
> > done
> 
> Thanks for the updated script, you are right, it was localized for my
> system.
> 
> > Even with this, I'm not convinced, due to the high number of false
> > positives (generated cache files, directories not explicitly packaged,
> > etc...) it is hard to make sense of the output.
> 
> Really?  I see almost none of that on my openSUSE boxes.

119 entries on my openSUSE 11.3 box. 14 links, 28 directories, 77 files.

All links are from /usr/share/man/man1 to /etc/alternatives, definitely
harmless. Directories as far as I can see are mostly forgotten entries
in spec files, that should be added (if nothing else, so that said
directories are removed on rpm -e, I think it's not the case if they
aren't listed in the spec file.)

False positive for files fall into two categories, mime type xml files
and font cache files. After filtering these out, I am down to 4 entries:

Weird file /usr/share/ccsm/icons/hicolor/scalable/apps/plugin-workspacenames.svg, please check this out
Weird file /usr/share/doc/corefonts/EULA.html, please check this out
Weird file /usr/share/fonts/truetype/impact.ttf, please check this out
Weird file /usr/share/guile/1.8/slibcat, please check this out

The two middle ones are probably from fetchmsttfonts, I'll look into
fixing them. The first one I seem to recall installing myself, and the
last one claims to be auto-generated and doesn't look like a threat.

> > We'd need to fix all
> > the packages first so that only actual changes are returned by the
> > script.
> > 
> > I'm also unsure why /usr/share would be a better target than any other
> > system directory.
> 
> It's a very common place for rootkits to hide their files.
> 
> And they look pretty obvious when you see them, so they will not just
> blend in with the other "normal" files you describe above.  So it's
> still a good thing to run to check your system to help ensure that it is
> clean.

I did, no problem, and thanks for the hints!

-- 
Jean Delvare