signed tarballs

signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 286 bytes --]

Hello,
I am the maintainer of 'audit' in the official Arch Linux Repositories.
Is there a reason why you don't provide a signature file for the
releases nor a checksum or am I just stupid and can't find it on your
website: https://people.redhat.com/sgrubb/audit/ ?

Best regards,
chris

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 545 bytes --]

Why not just checkout the release with git?

On Apr 6, 2017 16:36, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
wrote:

> Hello,
> I am the maintainer of 'audit' in the official Arch Linux Repositories.
> Is there a reason why you don't provide a signature file for the
> releases nor a checksum or am I just stupid and can't find it on your
> website: https://people.redhat.com/sgrubb/audit/ ?
>
> Best regards,
> chris
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

[-- Attachment #1.2: Type: text/html, Size: 1127 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 406 bytes --]

On Thu, Apr 06, 2017 at 06:27:08PM -0700, William Roberts wrote:
> Why not just checkout the release with git?

Because this wouldn't solve the problem or do you use signed commits in
your linux-audit git repository? And even if you use signed commits I
really would appreciate if you would sign the tarball and provide a hash
for it on the release page. This would increase security a lot.

cheers,
chris

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 663 bytes --]

On Apr 7, 2017 4:41 PM, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
wrote:

On Thu, Apr 06, 2017 at 06:27:08PM -0700, William Roberts wrote:
> Why not just checkout the release with git?

Because this wouldn't solve the problem or do you use signed commits in
your linux-audit git repository?


As long as you use a secure protocol and trust his repo signing the tags
doesn't give you all that much.

And even if you use signed commits I
really would appreciate if you would sign the tarball and provide a hash
for it on the release page. This would increase security a lot.


Yes agreed there, at least HTTPS connections are available.


cheers,
chris

[-- Attachment #1.2: Type: text/html, Size: 1560 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Paul Moore]

On Thu, Apr 6, 2017 at 7:31 PM, Christian Rebischke
<Chris.Rebischke@archlinux.org> wrote:
> Hello,
> I am the maintainer of 'audit' in the official Arch Linux Repositories.
> Is there a reason why you don't provide a signature file for the
> releases nor a checksum or am I just stupid and can't find it on your
> website: https://people.redhat.com/sgrubb/audit/ ?

Steve seems to be posting audit userspace releases both on his Red Hat
people page and on GitHub; I'm not sure which he considers to be the
"authoritative" release, he'll have to answer that.

https://github.com/linux-audit/audit-userspace/releases

As far as checksum'd and signed releases, someone from the Debian camp
recently requested detached signatures for libseccomp and provided the
documentation below (it's a short and well done doc).  While
libseccomp had been signing releases for years, we were using a
combined (?) approach, it was relatively easy to add the detached
signature.

https://wiki.debian.org/Creating%20signed%20GitHub%20releases

In case anyone is interested, here is an example of what we now
provide for a libseccomp release:

https://github.com/seccomp/libseccomp/releases/tag/v2.3.2

... and the libseccomp release process is documented here:

https://github.com/seccomp/libseccomp/blob/master/RELEASE_PROCESS.md

-- 
paul moore
www.paul-moore.com

Re: signed tarballs

[Steve Grubb]

On Thursday, April 6, 2017 7:31:35 PM EDT Christian Rebischke wrote:
> Hello,
> I am the maintainer of 'audit' in the official Arch Linux Repositories.
> Is there a reason why you don't provide a signature file for the
> releases nor a checksum or am I just stupid and can't find it on your
> website: https://people.redhat.com/sgrubb/audit/ ?

Nobody has ever asked for one. I literally build the package in Fedora within 
a few minutes of a release. Fedora has hashes of the audit tar file in the 
"sources" file in the build system in case you want any historical 
information:

http://pkgs.fedoraproject.org/cgit/rpms/audit.git/log/sources

-Steve

Re: signed tarballs

[Steve Grubb]

On Saturday, April 8, 2017 8:53:10 AM EDT Paul Moore wrote:
> > I am the maintainer of 'audit' in the official Arch Linux Repositories.
> > Is there a reason why you don't provide a signature file for the
> > releases nor a checksum or am I just stupid and can't find it on your
> > website: https://people.redhat.com/sgrubb/audit/ ?
> 
> Steve seems to be posting audit userspace releases both on his Red Hat
> people page and on GitHub; I'm not sure which he considers to be the
> "authoritative" release, he'll have to answer that.
> 
> https://github.com/linux-audit/audit-userspace/releases

I consider the ones from the people page to be authoritative because its been 
converted from raw, unprocessed development files to a distribution tarball by 
use of the autotools. This involves running autogen.sh, ./configure, and then 
make dist-check. Starting with the 2.7.5 release, I changed the naming 
convention on github to make sure people can tell the difference when looking 
at the release from the people page vs github.

-Steve

Re: signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]

On Mon, Apr 10, 2017 at 02:35:31PM -0400, Steve Grubb wrote:
> Nobody has ever asked for one. I literally build the package in Fedora within 
> a few minutes of a release. Fedora has hashes of the audit tar file in the 
> "sources" file in the build system in case you want any historical 
> information:
> 
> http://pkgs.fedoraproject.org/cgit/rpms/audit.git/log/sources
> 

Hello Steve,
well.. then I want to ask you if you could use gpg signatures in future
for your releases. We, at arch linux, are currently encouraging upstream
to use signed releases and https. It's just 5min of work and it's a big
step to a more secure internet. Thanks.

chris

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Steve Grubb]

On Tuesday, April 11, 2017 6:44:13 AM EDT Christian Rebischke wrote:
> On Mon, Apr 10, 2017 at 02:35:31PM -0400, Steve Grubb wrote:
> > Nobody has ever asked for one. I literally build the package in Fedora
> > within a few minutes of a release. Fedora has hashes of the audit tar
> > file in the "sources" file in the build system in case you want any
> > historical information:
> > 
> > http://pkgs.fedoraproject.org/cgit/rpms/audit.git/log/sources
> 
> Hello Steve,
> well.. then I want to ask you if you could use gpg signatures in future
> for your releases. We, at arch linux, are currently encouraging upstream
> to use signed releases and https. It's just 5min of work and it's a big
> step to a more secure internet. Thanks.

I added a sha256sum to the release announcement yesterday. You can also access 
the people page via https.

-Steve

Re: signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 318 bytes --]

On Tue, Apr 11, 2017 at 10:03:54AM -0400, Steve Grubb wrote:
> I added a sha256sum to the release announcement yesterday. You can also access 
> the people page via https.
> 

Thanks, but as I stated before. SHA256 and https doesn't ensure a
non-malicious tarball. Only a signed tarball can achieve this.




[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 631 bytes --]

On Apr 13, 2017 13:28, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
wrote:

On Tue, Apr 11, 2017 at 10:03:54AM -0400, Steve Grubb wrote:
> I added a sha256sum to the release announcement yesterday. You can also
access
> the people page via https.
>

Thanks, but as I stated before. SHA256 and https doesn't ensure a
non-malicious tarball. Only a signed tarball can achieve this.


That's not true, he's providing you a detached signature via this
mechanism. You just need to check the sha256sum before extraction.





--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

[-- Attachment #1.2: Type: text/html, Size: 1445 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Steve Grubb]

On Thursday, April 13, 2017 4:30:57 PM EDT William Roberts wrote:
> On Apr 13, 2017 13:28, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
> wrote:
> 
> On Tue, Apr 11, 2017 at 10:03:54AM -0400, Steve Grubb wrote:
> > I added a sha256sum to the release announcement yesterday. You can also
> > access the people page via https.
> 
> Thanks, but as I stated before. SHA256 and https doesn't ensure a
> non-malicious tarball. Only a signed tarball can achieve this.
> 
> That's not true, he's providing you a detached signature via this
> mechanism. You just need to check the sha256sum before extraction.

Yeah, MD5 = collisions. SHA-1 = collisions. SHA-2 no known collisions. NIST 
found during the SHA-3 competition that SHA-2 was much more robust than 
previously thought.

-Steve

Re: signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 673 bytes --]

On Thu, Apr 13, 2017 at 01:30:57PM -0700, William Roberts wrote:

> That's not true, he's providing you a detached signature via this
> mechanism. You just need to check the sha256sum before extraction.

The problem with providing only a SHA256 hash is that the hash was
provide via an insecure channel. I can't be sure that the hash is really
from him because he didn't even sign his mails. Someone could spoof his
mail or MITM in the webserver with the tarballs, etc etc..

The only secure way to ensure the original content of the tarball is via
signed tarballs signed by the developer.

Checksums and signed tarballs are totally two different things.



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 849 bytes --]

On Apr 13, 2017 13:56, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
wrote:

On Thu, Apr 13, 2017 at 01:30:57PM -0700, William Roberts wrote:

> That's not true, he's providing you a detached signature via this
> mechanism. You just need to check the sha256sum before extraction.

The problem with providing only a SHA256 hash is that the hash was
provide via an insecure channel. I can't be sure that the hash is really
from him because he didn't even sign his mails. Someone could spoof his
mail or MITM in the webserver with the tarballs, etc etc..


Isn't the hash on the https people's page? Which last time I looked wasnt
throwing cert errors in chrome.


The only secure way to ensure the original content of the tarball is via
signed tarballs signed by the developer.

Checksums and signed tarballs are totally two different things.

[-- Attachment #1.2: Type: text/html, Size: 1561 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Paul Moore]

On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> Isn't the hash on the https people's page? Which last time I looked wasnt
> throwing cert errors in chrome.

Unless Steve has exclusive administrative access to people.redhat.com
(I think it is safe to say he does not, but correct me if I'm wrong
Steve <b>) you can't trust an unsigned checksum regardless of how
strong the https cert/crypto as the web admin could still tamper with
the data.

-- 
paul moore
www.paul-moore.com

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 700 bytes --]

On Apr 13, 2017 14:05, "Paul Moore" <paul@paul-moore.com> wrote:

On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> Isn't the hash on the https people's page? Which last time I looked wasnt
> throwing cert errors in chrome.

Unless Steve has exclusive administrative access to people.redhat.com
(I think it is safe to say he does not, but correct me if I'm wrong
Steve <b>) you can't trust an unsigned checksum regardless of how
strong the https cert/crypto as the web admin could still tamper with
the data.


Sure possible, but not super plausible. You're putting some trust in the
administration of that website to begin with.


--
paul moore
www.paul-moore.com

[-- Attachment #1.2: Type: text/html, Size: 1592 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Paul Moore]

On Thu, Apr 13, 2017 at 5:08 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> On Apr 13, 2017 14:05, "Paul Moore" <paul@paul-moore.com> wrote:
>> Unless Steve has exclusive administrative access to people.redhat.com
>> (I think it is safe to say he does not, but correct me if I'm wrong
>> Steve <b>) you can't trust an unsigned checksum regardless of how
>> strong the https cert/crypto as the web admin could still tamper with
>> the data.
>
> Sure possible, but not super plausible. You're putting some trust in the
> administration of that website to begin with.

Come one man, you're smarter than this :)

I only called out the malicious admin case, but there are other cases
where someone with malicious intent could tamper with the checksum.
Some quick examples: hacked webserver, MITM https proxy, etc.

-- 
paul moore
security @ redhat

Re: signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 1923 bytes --]

On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote:
> Unless Steve has exclusive administrative access to people.redhat.com
> (I think it is safe to say he does not, but correct me if I'm wrong
> Steve <b>) you can't trust an unsigned checksum regardless of how
> strong the https cert/crypto as the web admin could still tamper with
> the data.

We are not only talking about the web admin. We live in times where
governments can easily tamper such data and the documents from snowden
and some other whistleblowers prove that they did stuff like this.

The only way to make sure that the tarball is the original tarball is
with a signature from Steve grubbs gpg-key. This would ensure that steve
has checked the content.

Just imagine the following scenario:

1. New audit version
2. Steve uploads the new version with new hash to the webserver.

3. Let's imagine that hackers would MITM my connection or modify the
server content. They could deploy a new tarball and generate a new
checksum for it, because SHA256 is just *one* factor. Everyone who would
download the new tarball would check against the new malicious hash.

This is a valid attack scenario.. This scenario could only be prevent by
using signed tarballs. Because people like me and other distribution
maintainers would have Steves pubkey. If somebody would modify the
tarball he would need Steves pubkey. And this is much more difficult
than just MITM the connection or tampering the data on the webserver.

With a signed tarball the attacker would have following problems:

1. the attacker can't deploy a malicious tarball without signature,
because this would make clear that the tarball is malicious.
2. if the attacker would generate an own signature for the maliciois
tarball, people who verify the tarball would get a warning because the
key is unknown and not part of steves keyring.

I hope this email is clearer...

Thanks for reading.



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Steve Grubb]

On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote:
> On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
> 
> <bill.c.roberts@gmail.com> wrote:
> > Isn't the hash on the https people's page?

No, its on the mail list. The mail list is moderated. Only a handful of people 
could post a spoofed message.

> > Which last time I looked wasnt throwing cert errors in chrome.
> 
> Unless Steve has exclusive administrative access to people.redhat.com
> (I think it is safe to say he does not, but correct me if I'm wrong
> Steve <b>) 

Nope.

> you can't trust an unsigned checksum regardless of how
> strong the https cert/crypto as the web admin could still tamper with
> the data.

They would have to go tamper with the mail list where all the hashes are 
publicly disclosed, too. There are multiple mail list archives. Then they 
would have to post the tampered tarball to the Fedora Build System which also 
publicly discloses hashs. And the Fedora Build System requires several 
identity checks to check it in and it maintains a log.

You might get one, but you can't get them all. I'd say just a simple check of 
the hash would catch most problems. If not, then I'd trust what's in Fedora 
over the people page.

-Steve

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 1295 bytes --]

On Apr 13, 2017 14:17, "Paul Moore" <pmoore@redhat.com> wrote:

On Thu, Apr 13, 2017 at 5:08 PM, William Roberts
<bill.c.roberts@gmail.com> wrote:
> On Apr 13, 2017 14:05, "Paul Moore" <paul@paul-moore.com> wrote:
>> Unless Steve has exclusive administrative access to people.redhat.com
>> (I think it is safe to say he does not, but correct me if I'm wrong
>> Steve <b>) you can't trust an unsigned checksum regardless of how
>> strong the https cert/crypto as the web admin could still tamper with
>> the data.
>
> Sure possible, but not super plausible. You're putting some trust in the
> administration of that website to begin with.

Come one man, you're smarter than this :)

I only called out the malicious admin case, but there are other cases
where someone with malicious intent could tamper with the checksum.
Some quick examples: hacked webserver, MITM https proxy, etc.


It's all about trust, I could sign my tarballs and plop the private key
somewhere dumb. This is why pki is hard. There's always flaws, I consider
https + hash to be like a medium level of trust, and definitely an
improvement over nothing. Nothing will beat a signed blob, and we'll assume
Steve uses a smart card stored in a vault and only ever used for signing
releases with.


--
paul moore
security @ redhat

[-- Attachment #1.2: Type: text/html, Size: 2305 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[William Roberts]

[-- Attachment #1.1: Type: text/plain, Size: 2464 bytes --]

On Apr 13, 2017 14:22, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
wrote:

On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote:
> Unless Steve has exclusive administrative access to people.redhat.com
> (I think it is safe to say he does not, but correct me if I'm wrong
> Steve <b>) you can't trust an unsigned checksum regardless of how
> strong the https cert/crypto as the web admin could still tamper with
> the data.

We are not only talking about the web admin. We live in times where
governments can easily tamper such data and the documents from snowden
and some other whistleblowers prove that they did stuff like this.

The only way to make sure that the tarball is the original tarball is
with a signature from Steve grubbs gpg-key. This would ensure that steve
has checked the content.

Just imagine the following scenario:

1. New audit version
2. Steve uploads the new version with new hash to the webserver.

3. Let's imagine that hackers would MITM my connection or modify the
server content. They could deploy a new tarball and generate a new
checksum for it, because SHA256 is just *one* factor. Everyone who would
download the new tarball would check against the new malicious hash.

This is a valid attack scenario.. This scenario could only be prevent by
using signed tarballs. Because people like me and other distribution
maintainers would have Steves pubkey. If somebody would modify the
tarball he would need Steves pubkey. And this is much more difficult
than just MITM the connection or tampering the data on the webserver.

With a signed tarball the attacker would have following problems:

1. the attacker can't deploy a malicious tarball without signature,
because this would make clear that the tarball is malicious.
2. if the attacker would generate an own signature for the maliciois
tarball, people who verify the tarball would get a warning because the
key is unknown and not part of steves keyring.

I hope this email is clearer...


You're assuming a lot for an attack to happen, and your assuming a state of
steves security of his key, his repo, etc at release time. Pki is based on
trust of confidentiality of the private key. If Steve starts signing the
tarballs, it would be great (everyone should), but https + hash is better
then nothing, that's my point. The difference really boils down to trust of
the key, admin vs Steve. Admin vs Steve is much better than united vs Steve
;-).


Thanks for reading.

[-- Attachment #1.2: Type: text/html, Size: 3403 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: signed tarballs

[Steve Grubb]

On Thursday, April 13, 2017 6:45:55 PM EDT William Roberts wrote:
> On Apr 13, 2017 14:22, "Christian Rebischke" <Chris.Rebischke@archlinux.org>
> wrote:
> 
> On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote:
> > Unless Steve has exclusive administrative access to people.redhat.com
> > (I think it is safe to say he does not, but correct me if I'm wrong
> > Steve <b>) you can't trust an unsigned checksum regardless of how
> > strong the https cert/crypto as the web admin could still tamper with
> > the data.
> 
> We are not only talking about the web admin. We live in times where
> governments can easily tamper such data and the documents from snowden
> and some other whistleblowers prove that they did stuff like this.
> 
> The only way to make sure that the tarball is the original tarball is
> with a signature from Steve grubbs gpg-key. This would ensure that steve
> has checked the content.
> 
> Just imagine the following scenario:
> 
> 1. New audit version
> 2. Steve uploads the new version with new hash to the webserver.
> 
> 3. Let's imagine that hackers would MITM my connection or modify the
> server content. They could deploy a new tarball and generate a new
> checksum for it, because SHA256 is just *one* factor. Everyone who would
> download the new tarball would check against the new malicious hash.
> 
> This is a valid attack scenario.. This scenario could only be prevent by
> using signed tarballs. Because people like me and other distribution
> maintainers would have Steves pubkey. If somebody would modify the
> tarball he would need Steves pubkey. And this is much more difficult
> than just MITM the connection or tampering the data on the webserver.
> 
> With a signed tarball the attacker would have following problems:
> 
> 1. the attacker can't deploy a malicious tarball without signature,
> because this would make clear that the tarball is malicious.
> 2. if the attacker would generate an own signature for the maliciois
> tarball, people who verify the tarball would get a warning because the
> key is unknown and not part of steves keyring.
> 
> I hope this email is clearer...
> 
> 
> You're assuming a lot for an attack to happen, and your assuming a state of
> steves security of his key, his repo, etc at release time. Pki is based on
> trust of confidentiality of the private key. If Steve starts signing the
> tarballs, it would be great (everyone should), but https + hash is better
> then nothing, that's my point. The difference really boils down to trust of
> the key, admin vs Steve. Admin vs Steve is much better than united vs Steve
> ;-).

Indeed. I think the most plausible issue anyone would ever run across is the 
bugs that I may have inadvertently put in the code base rather than a MITM at 
the very second a distro is downloading a new release. How closely is anyone 
checking this code? Any fuzzers? Static analysis? Test suites?  :-) 

I understand the desire for source integrity. We'll go with hashes now and 
work up to signing another day. Meanwhile...how about some bug reports? Trust 
me. They are there.

-Steve

Re: signed tarballs

[Paul Moore]

On Thu, Apr 13, 2017 at 6:25 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote:
>> On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
>>
>> <bill.c.roberts@gmail.com> wrote:
>> > Isn't the hash on the https people's page?
>
> No, its on the mail list. The mail list is moderated. Only a handful of people
> could post a spoofed message.
>
>> > Which last time I looked wasnt throwing cert errors in chrome.
>>
>> Unless Steve has exclusive administrative access to people.redhat.com
>> (I think it is safe to say he does not, but correct me if I'm wrong
>> Steve <b>)
>
> Nope.
>
>> you can't trust an unsigned checksum regardless of how
>> strong the https cert/crypto as the web admin could still tamper with
>> the data.
>
> They would have to go tamper with the mail list where all the hashes are
> publicly disclosed, too. There are multiple mail list archives. Then they
> would have to post the tampered tarball to the Fedora Build System which also
> publicly discloses hashs. And the Fedora Build System requires several
> identity checks to check it in and it maintains a log.

No.  Since there is no authentication to post to this public email
list all they would have to do is spoof bogus a release announcement
email from you; yes there are some measures in place to combat things
like this, but it isn't that hard.  Granted, you might notice this
attack relatively quickly, but if the attack was timed to happen while
you were away from your email for an extended period of time (travel,
etc.) the window could be non-trivial, and even then, how many
installs could have already been put at risk?

Steve, it's pretty apparent at this point that you don't want to, and
aren't likely to, provide any form of signed checksum for the audit
userspace release.  That's your prerogative, and to some like William,
they may be content with that level of risk.  However, please don't
pretend that signing releases doesn't provide an additional layer of
protection.

-- 
paul moore
www.paul-moore.com

Re: signed tarballs

[Steve Grubb]

On Friday, April 14, 2017 9:06:53 AM EDT Paul Moore wrote:
> On Thu, Apr 13, 2017 at 6:25 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote:
> >> On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
> >> 
> >> <bill.c.roberts@gmail.com> wrote:
> >> > Isn't the hash on the https people's page?
> > 
> > No, its on the mail list. The mail list is moderated. Only a handful of
> > people could post a spoofed message.
> > 
> >> > Which last time I looked wasnt throwing cert errors in chrome.
> >> 
> >> Unless Steve has exclusive administrative access to people.redhat.com
> >> (I think it is safe to say he does not, but correct me if I'm wrong
> >> Steve <b>)
> > 
> > Nope.
> > 
> >> you can't trust an unsigned checksum regardless of how
> >> strong the https cert/crypto as the web admin could still tamper with
> >> the data.
> > 
> > They would have to go tamper with the mail list where all the hashes are
> > publicly disclosed, too. There are multiple mail list archives. Then they
> > would have to post the tampered tarball to the Fedora Build System which
> > also publicly discloses hashs. And the Fedora Build System requires
> > several identity checks to check it in and it maintains a log.
> 
> No.  Since there is no authentication to post to this public email
> list all they would have to do is spoof bogus a release announcement
> email from you; yes there are some measures in place to combat things
> like this, but it isn't that hard.  Granted, you might notice this
> attack relatively quickly, but if the attack was timed to happen while
> you were away from your email for an extended period of time (travel,
> etc.) the window could be non-trivial, and even then, how many
> installs could have already been put at risk?
> 
> Steve, it's pretty apparent at this point that you don't want to, and
> aren't likely to, provide any form of signed checksum for the audit
> userspace release.  That's your prerogative, and to some like William,
> they may be content with that level of risk.  However, please don't
> pretend that signing releases doesn't provide an additional layer of
> protection.

As I said in a subsequent email, "we'll go with hashes now and 
work up to signing another day." But I really am serious that the biggest 
threat to the project is not some wild eyed MITM attack targeting a whole 
distribution. Its me. I doubt few people truly understand the impact of the 
bug that Laurent reported and why it moved me to change plans and do a quick 
release. (It was not because ausearch was segfaulting.) Again, I call for more 
testing and bug reports. I know they are in the code. I find a couple every 
day or two.

-Steve

Re: signed tarballs

[Christian Rebischke]

[-- Attachment #1.1: Type: text/plain, Size: 829 bytes --]

On Fri, Apr 14, 2017 at 09:38:51AM -0400, Steve Grubb wrote:
> As I said in a subsequent email, "we'll go with hashes now and 
> work up to signing another day." But I really am serious that the biggest 
> threat to the project is not some wild eyed MITM attack targeting a whole 
> distribution. Its me. I doubt few people truly understand the impact of the 
> bug that Laurent reported and why it moved me to change plans and do a quick 
> release. (It was not because ausearch was segfaulting.) Again, I call for more 
> testing and bug reports. I know they are in the code. I find a couple every 
> day or two.

Yep, the first factor is the code. But keep in mind that signing
tarballs are just 5 minutes of work per release. I see no reason why
audit shouldn't do it, all other redhat projects do it too.




[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]