[arch-general] Sébastien Luttringer and Tobias Powalowski
morten at linderud.pw
Sun Jul 2 22:29:44 UTC 2017
On Mon, Jul 03, 2017 at 12:25:22AM +0200, NicoHood wrote:
> On 07/03/2017 12:21 AM, Morten Linderud wrote:
> > On Mon, Jul 03, 2017 at 12:16:53AM +0200, NicoHood wrote:
> >> On 07/03/2017 12:07 AM, Morten Linderud wrote:
> >>> On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote:
> >>>> Yes the GPG signature of the tag commit is checked. However you can
> >>>> attack the git metadata and set a tag to a different commit. If this
> >>>> commit is signed, but at an older stage which is vulnearable, we have an
> >>>> issue. Just one example. So we should always also secure the transport
> >>>> layer.
> >>>> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
> >>> The sign includes the hash. You would essentially have to trick Lennart into replacing the tag to a different commit,
> >>> and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. At this point i think we have bigger
> >>> problems then whatever the PKGBUILD is doing...
> >> Thats is exactly what I mean. If I understood right you can modify the
> >> git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
> >> is gpg signed and all valid. This seems to work for me.
> > But at this point you can't trust critical maintainers of important software. This isn't a threat model i think
> > PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are you implying MITM attacks can trick the
> > packager into packaging broken software?
> Sure it is all about MITM, as we are talking about using https over
> http. I am not sure if I am right. But why are we even discussing if
> https is available? It will just make things better.
But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life.
Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he
wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.
You also didn't really reply about the threat model.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the arch-general