Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Leonid Isaev]

On Tue, Nov 01, 2016 at 03:59:28AM +0100, Lukas Rose wrote:
> > On 01 Nov 2016, at 00:35, Leonid Isaev  
> > wrote:
> > 
> > Well, my mentality is that authenticating plain-text data is usually not
> > necessary because a user can always inspect it
> 
> You just can't reliably inspect plain text install data, unless you spend an
> awful lot of time on it. As already pointed out, it's just too easy to miss
> out small malicious changes. And even if you were able to spot those, most
> average users won't, and that's what policies are meant for: the average
> user.

Perhaps you should try it yourself instead of arguing? I have been doing this
since 2010 with about 50 packages. PKGBUILDs are not usually long and therefore
easy to grasp with a single glance.

> > Regarding checksums, how did a dev know that upstream sources are authentic?
> 
> It's not about the upstream source to be authentic, it's about the upstream
> source reached your hard drive without further (malicious) modification. That
> saying, you can't expect a package maintainer to review all the code he uses
> (indirectly) in his package. If you use another (open source) project, that
> one could always be malicious. But we'll assume that case not likely (in
> general).

On the contrary, planting backdoors in OSS projects is a very likely scenario,
that has happened multiple times already [1-3]...

> It is much more likely that an attacker will try to break things
> you install (although I still assume that this is not often), than a group of
> attackers hiding malicious software in an (open source) project.

Where is such confifence coming from?

> The former
> can be easily locked out by checksums, the latter only by extensive code
> reviews. And even if they were done, you'd still have to trust the one who
> did the review. Since there's an easy fix for the former, let's use it. Since
> there is none for the latter, let's keep an eye on this. There's always trust
> to a certain degree.

I can't really disentangle this pile of... thoughts.

Cheers,
L.

[1] https://en.wikipedia.org/wiki/Vsftpd
[2] 
http://arstechnica.com/business/2012/02/malicious-backdoor-in-open-source-messaging-apps-not-spotted-for-4-months/
[3] 
http://security.stackexchange.com/questions/23334/example-of-a-backdoor-submitted-to-an-open-source-project

> 
> Cheers, Lukas

-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Lukas Rose]

> On 01 Nov 2016, at 00:35, Leonid Isaev  wrote:
> 
> Well, my mentality is that authenticating plain-text data is usually not
> necessary because a user can always inspect it

You just can't reliably inspect plain text install data, unless you spend an 
awful lot of time on it. As already pointed out, it's just too easy to miss out 
small malicious changes. And even if you were able to spot those, most average 
users won't, and that's what policies are meant for: the average user.

> Regarding checksums, how did a dev know that upstream sources are authentic?

It's not about the upstream source to be authentic, it's about the upstream 
source reached your hard drive without further (malicious) modification. That 
saying, you can't expect a package maintainer to review all the code he uses 
(indirectly) in his package. If you use another (open source) project, that one 
could always be malicious. But we'll assume that case not likely (in general). 
It is much more likely that an attacker will try to break things you install 
(although I still assume that this is not often), than a group of attackers 
hiding malicious software in an (open source) project. The former can be easily 
locked out by checksums, the latter only by extensive code reviews. And even if 
they were done, you'd still have to trust the one who did the review. Since 
there's an easy fix for the former, let's use it. Since there is none for the 
latter, let's keep an eye on this. There's always trust to a certain degree.

Cheers, Lukas

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Eli Schwartz via arch-general]

On 10/31/2016 07:35 PM, Leonid Isaev wrote:
> Regarding checksums, how did a dev know that upstream sources are authentic?

Personally, I check the upstream sources of stuff I publish to the AUR.
I maintain an additional *-git package for anything that makes sense
that way, so it is easy to diff/log.

-- 
Eli Schwartz

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Allan McRae]

On 01/11/16 03:14, Bennett Piater wrote:
> On 10/31/2016 06:04 PM, Levente Polyak wrote:
>> On the other side we have a dev/TU authenticating the buildscript.
>> Both cover certain areas but are still independent and one does not make
>> the other futile.
> 
> Since this thread is helpfully on arch-general now, I want to quickly
> chime in and say that I would really like authenticated buildscripts at
> some point :)
> 

I would like some bourbon.

Allan




* It might appear unrelated, but I can spend time on pacman/makepkg if I
don't have to work for bourbon.  Then again, bourbon reduces the quality
of my coding after a point...

** makepkg --source --sign

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Leonid Isaev]

On Mon, Oct 31, 2016 at 07:18:01PM -0400, Eli Schwartz via arch-general wrote:
> On 10/31/2016 05:50 PM, Leonid Isaev wrote:
> > As a side question... is there a significant difference in signing PKGBUILD 
> > vs
> > the compiled package.
> 
> Do you realize, when you ask if there is a difference between signing a
> PKGBUILD vs. a built package, it sounds an awful lot like asking if
> there is a difference between a PKGBUILD and a built package?

It does not, really...

> > Given that when building a pkg, I inspect the PKGBUILD,
> > what attack is possible when the PKGBUILD is not signed?
> 
> Off the top of my head, there is *the topic of this thread*. Someone
> could modify the checksums and deliver fake sources. When the PKGBUILD
> just says "run `make`", how do you tell the difference?

Well, my mentality is that authenticating plain-text data is usually not
necessary because a user can always inspect it (notice, I don't care if a
PKGBUILD comes from an authentic source, I only care if its not doing smth
malicious). This is why I inspect the PKGBUILD and corresponding install files
/ patches. At least, I thought this is why PKGBUILDs are not signed in the same
manner that Gentoo signs ebuilds...

Regarding checksums, how did a dev know that upstream sources are authentic? I
use a similar judgement (as a practical example, in my packages I always
maintain multiple checksums: one from Arch, another from Gentoo, third from
Debian/Fedora, and have a keyring with all upstream keys I can get).

But anyway, my question has already been answered...

Thanks,
L.

-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Eli Schwartz via arch-general]

On 10/31/2016 05:50 PM, Leonid Isaev wrote:
> As a side question... is there a significant difference in signing PKGBUILD vs
> the compiled package.

Do you realize, when you ask if there is a difference between signing a
PKGBUILD vs. a built package, it sounds an awful lot like asking if
there is a difference between a PKGBUILD and a built package?

Well, of course there is a difference. They are two different things...

> Given that when building a pkg, I inspect the PKGBUILD,
> what attack is possible when the PKGBUILD is not signed?

Off the top of my head, there is *the topic of this thread*. Someone
could modify the checksums and deliver fake sources. When the PKGBUILD
just says "run `make`", how do you tell the difference?

-- 
Eli Schwartz

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Levente Polyak]

On 10/31/2016 10:50 PM, Leonid Isaev wrote:
> On Mon, Oct 31, 2016 at 06:04:48PM +0100, Levente Polyak wrote:
>> I get your point what you try to achieve but the PKGBUILD already
>> contains the integrity values (checksums) for all external sources and
>> if you sign the PKGBUILD (which is the build script) then you have
>> implicitly authenticated all integrity values of the external sources.
>>
>> A signature is nothing more (but also nothing less) then an
>> authenticated checksum. If you sign a tarball then you "only" sign its hash.
>>
>> On top (like a bonus :P) if you sign the PKGBUILD then you did not only
>> authenticate the checksums of the external sources but also the
>> buildscript itself. So you really want so sign that instead ;)
> 
> As a side question... is there a significant difference in signing PKGBUILD vs
> the compiled package. Given that when building a pkg, I inspect the PKGBUILD,
> what attack is possible when the PKGBUILD is not signed?

Well that are two fundamentally different things. Signing the final
binary package authenticates that the one you received and want to
install is really what the dev/TU has built.

Signing the build-script (PKGBUILD) adds exactly this authentication to
the build-script that produced the given binary package. You obviously
only have advantage out of it if you are using that build-script for
anything (like building it yourself or for a rebuild by someone else).

It's exactly why you want to have signatures from upstream (authors): to
be sure who actually created it.
Reading the build-script is good and especially in the AUR quite
important... but at the end it mostly only saves you from obvious shit.
If there is anyone evil who alters it to attack you then I'm convinced
you most likely won't notice that by manually reading. It could be a
small security related change in an existing patch-file that comes with
the sources or as simple as a small swapped letter in the domain or
github username that is added to the source array of the PKGBUILD and
retrieves an evil version instead.

> Also, isn't the use of dev signature to validate upstream sources is a logical
> flaw? A dev might herself be mislead and build a trojaned source...
> 

Sure, but I never said or claimed anything else. That's why i always
insisted this to be a different topic (other then the original one).
What i specifically said is that you need both as they have fundamental
different areas they cover:

On 10/31/2016 06:04 PM, Levente Polyak wrote:
> Both cover certain areas but are still independent and one does not
> make the other futile.

By signing a PKGNBUILD of cause you don't "validate upstream sources" in
a way you described. No matter what, but to validate authenticity of an
upstream source, you obviously need an upstream signature.
What you gain is that you add the same authentication to the
build-script itself. Anyone obtaining a copy of it can verify it was
really created by a dev/TU and everything it used or pulled in (with or
without upstream signatures) is actually what that dev/TU had.

Again: You want to have both to cover different areas that one or the
other does not.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Leonid Isaev]

On Mon, Oct 31, 2016 at 06:04:48PM +0100, Levente Polyak wrote:
> I get your point what you try to achieve but the PKGBUILD already
> contains the integrity values (checksums) for all external sources and
> if you sign the PKGBUILD (which is the build script) then you have
> implicitly authenticated all integrity values of the external sources.
> 
> A signature is nothing more (but also nothing less) then an
> authenticated checksum. If you sign a tarball then you "only" sign its hash.
> 
> On top (like a bonus :P) if you sign the PKGBUILD then you did not only
> authenticate the checksums of the external sources but also the
> buildscript itself. So you really want so sign that instead ;)

As a side question... is there a significant difference in signing PKGBUILD vs
the compiled package. Given that when building a pkg, I inspect the PKGBUILD,
what attack is possible when the PKGBUILD is not signed?

Also, isn't the use of dev signature to validate upstream sources is a logical
flaw? A dev might herself be mislead and build a trojaned source...

Thx,
L.

-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] kde --> xfce how to remove all packages kde

[Jayesh Badwaik]

On Monday, 31 October 2016 22:27:54 CET David Demelier via arch-general wrote:
> Unfortunately even pacman -Rcsn plasma will leave some KDE packages. And I
> have never found any solution so far.

KDE is now not a single distribution, but rather a loose set of independent 
products. plasma is just the desktop part of it, you probably also want to 
uninstall kde-applications-meta.

https://wiki.archlinux.org/index.php/KDE#KDE_applications_and_language_packs

-- 
Cheers
Jayesh Badwaik

signature.asc
Description: This is a digitally signed message part.

Re: [arch-general] kde --> xfce how to remove all packages kde

[David Demelier via arch-general]

Le 30 oct. 2016 6:26 PM, "Merlin Büge"  a écrit :
>
> > Hi, I have migrate my archlinux system desktop kde to xfce.
> >
> > How to remove all kde packages and dependecy?
>
> https://wiki.archlinux.org/index.php/Pacman#Removing_packages
>
> Regards,

Unfortunately even pacman -Rcsn plasma will leave some KDE packages. And I
have never found any solution so far.

-- 
David Demelier

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Ivy Foster via arch-general]

On 31 Oct 2016, at  6:14 pm +0100, Bennett Piater wrote:
> I want to quickly chime in and say that I would really like
> authenticated buildscripts at some point :)

Any PKGBUILD kept in git can already optionally have this feature. See
git-commit(1), specifically, its --gpg-sign option.

iff

Re: [arch-general] [arch-dev-public] todo list for moving http -> https sources

[Carsten Mattner via arch-general]

When it comes to security of online update mechanisms and that of
an index, TUF has a well designed scheme to be safe regardless of
http and plan for eventual leak/theft of signing keys.

I'd suggest anyone interest to have a look.

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Bennett Piater]

On 10/31/2016 06:04 PM, Levente Polyak wrote:
> On the other side we have a dev/TU authenticating the buildscript.
> Both cover certain areas but are still independent and one does not make
> the other futile.

Since this thread is helpfully on arch-general now, I want to quickly
chime in and say that I would really like authenticated buildscripts at
some point :)

Cheers,
Bennett

-- 
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Levente Polyak]

On 10/31/2016 04:43 PM, Patrick Burroughs (Celti) wrote:
> On Mon, 31 Oct 2016 16:16:21 +0100
> Levente Polyak  wrote:
> 
>> On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
>>> As a middle ground, I think it would be more reasonable (or at
>>> least, less unreasonable) to modify makepkg to allow signing
>>> PKGBUILDs, or at least parts of them. For an existing example,
>>> OpenBSD's signify(1) uses their cryptographic signature system to
>>> sign a simple list sha256sums.
>>>
>>> Perhaps makepkg could include, e.g., a sha256sumsigs array, that
>>> contains a PGP signature (signed by the developer/TU's official key)
>>> of the contents (properly serialised by makepkg so there's a minimum
>>> of possible ambiguity) of the sha256sums array?
>>>   
>>
>> That is literally a _completely_ different topic that addresses
>> _completely_ different areas.
>> You are speaking about authenticating the build scripts itself. That
>> does not solve _anything_ at all what this thread/topic/todo-list is
>> about.
> 
> It really is not. I am not speaking of authenticating the build
> scripts; both this thread and my proposal are talking about ensuring
> the integrity of downloaded source files.

Well you wrote exactly that :P If I want to nitpick I could quote you:

>> On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
>>> As a middle ground, I think it would be more reasonable (or at
>>> least, less unreasonable) to modify makepkg to allow signing
>>> PKGBUILDs, or at least parts of them.

But never mind, that does not take us anywhere (i just could not resist)
:P So lets be productive and focus on advantages...

On 10/31/2016 04:43 PM, Patrick Burroughs (Celti) wrote:
> Specifically, I am speaking of cryptographically signing the checksums
> for source files downloaded by the build scripts, so that they download
> what the author of the build script _intended_ them to download.
> 

If you sign the PKGBUILDs you authenticate it. Where exactly is the
difference in what you are saying?
I get your point what you try to achieve but the PKGBUILD already
contains the integrity values (checksums) for all external sources and
if you sign the PKGBUILD (which is the build script) then you have
implicitly authenticated all integrity values of the external sources.

A signature is nothing more (but also nothing less) then an
authenticated checksum. If you sign a tarball then you "only" sign its hash.

On top (like a bonus :P) if you sign the PKGBUILD then you did not only
authenticate the checksums of the external sources but also the
buildscript itself. So you really want so sign that instead ;)

> This is presumably the same reason for ensuring sources are downloaded
> via HTTPS instead of HTTP, where possible — adding a cryptographic
> authentication to ensure someone building a package does not get
> sources without being aware they are modified: only embedding
> signatures in the PKGBUILD is trusting the Arch devs via the pacman
> keyring or parallel method, instead of the (flawed) CA system. If there
> is another reason to switch to HTTPS, please — make me aware of it! 

No its not. If you read the whole topic then you will see that Dave
already perfectly pointed that out: It's simply another layer of
security affecting the transport.
Even if we would say its additional value for integrity is small, that
would still mean its value is >0 (for adding a single letter :P).
Lets simply assume an attacker has prepared some source tarballs by
investing a lot of resources and time to create backdoored versions of
source tarballs and find a collision of the upstream signed checksums.
Then the attacker (assuming it has no access to the upstream server and
performs a man-in-the-middle attack) would still need to break TLS on
top of having the pre-collided backdoored sources.

Now is the perfect time to quote Dave: "you must consider that security
is not a binary thing". <3 :)

But regardless of that, the least thing that you get out of this is
confidentiality.

> I really, really don't think they're independent from each other, and
> as I'm not authorised to post on arch-dev-public and didn't expect to
> draw this out into a conversation, I simply replied to the thread on
> arch-general. Bowing to peers, however... et voila: a new thread.

Having all this said, I still have the opinion that its related but
still another topic.

On one side we have transport layer security plus upstream (author)
provided authentication of checksums (that's what a signature is).

On the other side we have a dev/TU authenticating the buildscript.
Both cover certain areas but are still independent and one does not make
the other futile.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] todo list for moving http -> https sources

[Diego Viola via arch-general]

On Mon, Oct 31, 2016 at 2:18 PM, Guillaume ALAUX
 wrote:
> On Mon, Oct 31, 2016 at 4:16 PM, Levente Polyak  
> wrote:
>>
>> On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
>> > As a middle ground, I think it would be more reasonable (or at least,
>> > less unreasonable) to modify makepkg to allow signing PKGBUILDs, or at
>> > least parts of them. For an existing example, OpenBSD's signify(1) uses
>> > their cryptographic signature system to sign a simple list sha256sums.
>> >
>> > Perhaps makepkg could include, e.g., a sha256sumsigs array, that
>> > contains a PGP signature (signed by the developer/TU's official key)
>> > of the contents (properly serialised by makepkg so there's a minimum
>> > of possible ambiguity) of the sha256sums array?
>> >
>>
>> That is literally a _completely_ different topic that addresses
>> _completely_ different areas.
>> You are speaking about authenticating the build scripts itself. That
>> does not solve _anything_ at all what this thread/topic/todo-list is about.
>>
>> Don't get me wrong: I don't judge about it at all, I'm just saying that
>> both are fully independent from each other and you should please open a
>> new thread if you want to discuss this rather then hijack this thread :)
>>
>> cheers,
>> Levente
>>
>
> Yes, these are two totally different subjects: "Encourage the use of
> PGP signatures in our `source`" and "Using HTTPS on our `source`".
> Let's stick to the original subject :)
>
> I am all in favor of a script to turn `http` into `https` when
> available. Yeah HTTPS "brings a false sense of security" but still it
> hardens a link in the build process. Sorry for your caches guys, I
> might miss some background here but I couldn't imagine any reason to
> go against adding some more security in our build process.

Thanks fnodeuser.

Re: [arch-general] [arch-dev-public] todo list for moving http -> https sources

[Guillaume ALAUX]

On Mon, Oct 31, 2016 at 4:16 PM, Levente Polyak  wrote:
>
> On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
> > As a middle ground, I think it would be more reasonable (or at least,
> > less unreasonable) to modify makepkg to allow signing PKGBUILDs, or at
> > least parts of them. For an existing example, OpenBSD's signify(1) uses
> > their cryptographic signature system to sign a simple list sha256sums.
> >
> > Perhaps makepkg could include, e.g., a sha256sumsigs array, that
> > contains a PGP signature (signed by the developer/TU's official key)
> > of the contents (properly serialised by makepkg so there's a minimum
> > of possible ambiguity) of the sha256sums array?
> >
>
> That is literally a _completely_ different topic that addresses
> _completely_ different areas.
> You are speaking about authenticating the build scripts itself. That
> does not solve _anything_ at all what this thread/topic/todo-list is about.
>
> Don't get me wrong: I don't judge about it at all, I'm just saying that
> both are fully independent from each other and you should please open a
> new thread if you want to discuss this rather then hijack this thread :)
>
> cheers,
> Levente
>

Yes, these are two totally different subjects: "Encourage the use of
PGP signatures in our `source`" and "Using HTTPS on our `source`".
Let's stick to the original subject :)

I am all in favor of a script to turn `http` into `https` when
available. Yeah HTTPS "brings a false sense of security" but still it
hardens a link in the build process. Sorry for your caches guys, I
might miss some background here but I couldn't imagine any reason to
go against adding some more security in our build process.

[arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Patrick Burroughs (Celti)]

On Mon, 31 Oct 2016 16:16:21 +0100
Levente Polyak  wrote:

> On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
> > As a middle ground, I think it would be more reasonable (or at
> > least, less unreasonable) to modify makepkg to allow signing
> > PKGBUILDs, or at least parts of them. For an existing example,
> > OpenBSD's signify(1) uses their cryptographic signature system to
> > sign a simple list sha256sums.
> > 
> > Perhaps makepkg could include, e.g., a sha256sumsigs array, that
> > contains a PGP signature (signed by the developer/TU's official key)
> > of the contents (properly serialised by makepkg so there's a minimum
> > of possible ambiguity) of the sha256sums array?
> >   
> 
> That is literally a _completely_ different topic that addresses
> _completely_ different areas.
> You are speaking about authenticating the build scripts itself. That
> does not solve _anything_ at all what this thread/topic/todo-list is
> about.

It really is not. I am not speaking of authenticating the build
scripts; both this thread and my proposal are talking about ensuring
the integrity of downloaded source files.

Specifically, I am speaking of cryptographically signing the checksums
for source files downloaded by the build scripts, so that they download
what the author of the build script _intended_ them to download.

This is presumably the same reason for ensuring sources are downloaded
via HTTPS instead of HTTP, where possible — adding a cryptographic
authentication to ensure someone building a package does not get
sources without being aware they are modified: only embedding
signatures in the PKGBUILD is trusting the Arch devs via the pacman
keyring or parallel method, instead of the (flawed) CA system. If there
is another reason to switch to HTTPS, please — make me aware of it! 

Also the very first reply in the thread talked about adding upstream
signatures instead of changing the protocol, where possible — only not
every upstream offers or _wants_ to offer them, so I proposed, in
response to a prompt for discussion on the subject in the mail I
quoted, a way to make that feasible.

> Don't get me wrong: I don't judge about it at all, I'm just saying
> that both are fully independent from each other and you should please
> open a new thread if you want to discuss this rather then hijack this
> thread :)

I really, really don't think they're independent from each other, and
as I'm not authorised to post on arch-dev-public and didn't expect to
draw this out into a conversation, I simply replied to the thread on
arch-general. Bowing to peers, however... et voila: a new thread.

~Celti


pgpQuhZs9eaZH.pgp
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] todo list for moving http -> https sources

[Levente Polyak]

On 10/31/2016 04:03 PM, Patrick Burroughs (Celti) wrote:
> As a middle ground, I think it would be more reasonable (or at least,
> less unreasonable) to modify makepkg to allow signing PKGBUILDs, or at
> least parts of them. For an existing example, OpenBSD's signify(1) uses
> their cryptographic signature system to sign a simple list sha256sums.
> 
> Perhaps makepkg could include, e.g., a sha256sumsigs array, that
> contains a PGP signature (signed by the developer/TU's official key)
> of the contents (properly serialised by makepkg so there's a minimum
> of possible ambiguity) of the sha256sums array?
> 

That is literally a _completely_ different topic that addresses
_completely_ different areas.
You are speaking about authenticating the build scripts itself. That
does not solve _anything_ at all what this thread/topic/todo-list is about.

Don't get me wrong: I don't judge about it at all, I'm just saying that
both are fully independent from each other and you should please open a
new thread if you want to discuss this rather then hijack this thread :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] todo list for moving http -> https sources

[Patrick Burroughs (Celti)]

On Mon, 31 Oct 2016 15:19:40 +0100
NicoHood  wrote:

> Using PGP signatures is another discussion, also the hash algorithm. I
> think we should discuss that in another post, appart from https. From
> my point of view its highly important to use a strong hash function
> as its highly important for the source integrity and not only meant
> as checksum for corruption detection. And as always: more secure does
> not hurt nowadays

Not a dev, here, but... I strongly think that source integrity should
not rely on hash functions alone. makepkg already includes validation of
PGP-signed sources, but it's perhaps not reasonable to expect every
upstream to offer signed sources.

As a middle ground, I think it would be more reasonable (or at least,
less unreasonable) to modify makepkg to allow signing PKGBUILDs, or at
least parts of them. For an existing example, OpenBSD's signify(1) uses
their cryptographic signature system to sign a simple list sha256sums.

Perhaps makepkg could include, e.g., a sha256sumsigs array, that
contains a PGP signature (signed by the developer/TU's official key)
of the contents (properly serialised by makepkg so there's a minimum
of possible ambiguity) of the sha256sums array?

~Celti


pgpp69w4ZogEY.pgp
Description: OpenPGP digital signature