Re: [aur-general] TU Application: Baptiste Jonglez

[Lukas Fleischer]

On Mon, 28 Nov 2016 at 07:33:16, Baptiste Jonglez wrote:
> I would like to apply to become a TU.  Lukas Fleischer has kindly accepted
> to sponsor my application.
> [...]
> Don't hesitate if you have any questions, or comments on my AUR packages!

The discussion period is over. Please cast your votes at [1].

[1] https://aur.archlinux.org/tu/?id=89

Re: [aur-general] TU Application: Baptiste Jonglez

[Johannes Löthberg via aur-general]

On 02/12, Giancarlo Razzolini wrote:

Em dezembro 2, 2016 11:18 NicoHood escreveu:


The signature itself is only a signed hash (sha256). So we do rely on
the collision resistance of sha256[1] (or whatever the GPG itself uses).
You are right, that hashes themselves are not enough to verify that the
original author provided this source. But it gives you the guarantee
that you downloaded the same source, as the maintainer(PKGBUILD writer) did.



GPG uses DSA[0]. And the signatures done using GPG are done in a way that
requires a key pair on the part of the person doing the signature. The
link you sent demonstrate precisely that. They are much more than simple
hashes.

[0] https://www.gnupg.org/gph/en/manual.html#AEN216


That's quite outdated, and RSA has been the default for quite a long 
time.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[NicoHood]

>>
>> Besides this issue, I already mentioned another drawback of using HTTPS:
>> untrusted certificates (either expired, self-signed, or just signed by an
>> untrusted CA) will cause build failure.  This was a real issue for
>> OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to
>> avoid build failures.  Sources are already validated with a checksum.
>>
>
> Well, relying only on checksums is not good enough in my opinion. We know
> for a fact that hashing algorithms are built on top of *reasonable* chance
> that collisions won't happen. Sure, the space of a SHA256 hash is
huge, but
> we must not just shrug over it. Because if we, as maintainers do, upstream
> will think they don't need to provide signed sources, because hashes are
> probably "good enough".
>

The signature itself is only a signed hash (sha256). So we do rely on
the collision resistance of sha256[1] (or whatever the GPG itself uses).
You are right, that hashes themselves are not enough to verify that the
original author provided this source. But it gives you the guarantee
that you downloaded the same source, as the maintainer(PKGBUILD writer) did.

That is what integrity is all about, that is not only a checksum! The
weakest spot though is the initial fetching of the source on which the
maintainer relies on. However with strong hashes you can at least ensure
that you (for a rebuild) download the exact same sources, as the
maintainer did. You just cannot prove who published that source itself.
Saying sha256 is not secure enough for that purpose would also say GPG
is not safe.

Correct me if I am wrong though. I'd be also nice to discuss this in the
email I recently opened and not in the TU Application. I think this is a
highly important topic, especially for those packages where we do not
have gpg and https available and you can only rely on the hash that the
maintainer gave out (AUR).

[1]https://www.bestvpn.com/wp-content/uploads/2015/03/Digital_Signature_diagram.png

Cheers
Nico




signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hi Nicohood,

On Thu, Dec 01, 2016 at 04:23:27PM +0100, NicoHood wrote:
> you do not need to move the packages as fast as possible into
> community. I became TU month ago and arduino is still not in community
> because some issues needed to be solved first. So quality and security
> is more important here.

Agreed.

> About all this https discussion:
> I think we should all confirm with the gpg and https standards we made
> recently (and the string hashes that i suggested) and we should also try
> to increase the quality of AUR in general and especially as TU to advise
> other people to do so too.
> Packaging a secure chat program and being so lazy about https makes me
> wonder.
> 
> I think it'd be good for you to rethink the https (and gpg, hash) topic,
> because (especially) as secure chat messenger packager it'd be extremely
> important to me that you try to achieve the best security as possible.

You almost sound like I'm opposing all forms of "security" (whatever you
mean by that).  Of course we should promote the use of TLS and HTTPS on
the Internet, even though the trust model is flawed and implementations
are bloated/bugged.

My point is that in the context of packaging, we have different
requirements than for web browsing.  HTTPS does not provide authenticity
and integrity of the sources themselves, which is what we are interested
in.  PGP (preferably) and strong hash algorithms (as a substitute) should
be used for that.

To avoid repeating the same arguments, I agree with what seblu said on
arch-dev-public:

On Tue, Nov 01, 2016 at 04:03:04PM +0100, Sébastien Luttringer wrote:
> TLS is about security of the transportation of sources, not the security
> of sources themselves, that's why I asked, to know what you had in mind.
> 
> My definition of securing the sources, is a way to trust the sources at
> the build time, no matter the way they were fetched. I want to be sure
> that my sources are "correct" even if I get them by usb key, ftp, rsync
> or even if they were not corrupted locally by a btrfs bug.  And when
> possible, I want to be sure that the server (mirror or not) was not
> compromised (even at the first fetch).
> 
> Keeping that in mind, enforcing tls, doesn't improve much the source
> security.  In fact, it improves only security during the transportation
> of the sources at the cost of the caching.

Besides this issue, I already mentioned another drawback of using HTTPS:
untrusted certificates (either expired, self-signed, or just signed by an
untrusted CA) will cause build failure.  This was a real issue for
OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to
avoid build failures.  Sources are already validated with a checksum.

Anyway, some of my packages do not use HTTPS, and this is indeed mostly
because of laziness.  I consider this is a low priority task.
It does not mean that I am fundamentally opposed to the use of HTTPS,
especially for "big" providers like github which are not very likely to
have expired certs.

I had a look at the sources for my AUR packages, and here is the result:

- 5 fetched over HTTPS
- 7 fetched over git+https://

- 5 fetched over HTTP, with no HTTPS available
- 1 fetched over FTP, with no HTTPS available

- 5 fetched over HTTP while HTTPS is available (including 1 with a PGP 
signature)
- 6 fetched over git:// while git+https:// is available

So, less than half of them needed to be "fixed".  I just switched to HTTPS
for 10 out of the 11 fixable packages.  The only remaining one is
linux-mptcp, because I plan to move it away from git soon anyway.

Baptiste

[1] 
https://git.lede-project.org/?p=openwrt/source.git;a=blobdiff;f=scripts/download.pl;h=633a4f6f7d;hp=fe27df5e8f;hb=65fad8645d;hpb=5884b43b51


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[NicoHood]

On 11/29/2016 12:08 PM, Levente Polyak wrote:
> On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
>> For a package in [community], an expired certificate for the upstream
>> tarball is not a big deal, since it does not directly affect the Arch user
>> installing the package.  As a packager, you can just get the tarball by
>> some other means, or wait a few days so that somebody renews the cert.
>>
>> But for the AUR, an expired certificate would be annoying, as any user
>> trying to build the package (e.g. using an AUR helper) would encounter an
>> error.
>>
> 
> I call bullshit, especially as your cases are purely about github!
> Surly, as if they can't wait "a few days" in such an unlikely scenario.
> And what if upstream forgets to pay for their servers, it won't be
> available too.
> How often do you think that certificates stay in an expired state. Of
> cause there may be one or two cases that could be named, its still
> certainly nothing to build upon.
> 


About all this https discussion:
I think we should all confirm with the gpg and https standards we made
recently (and the string hashes that i suggested) and we should also try
to increase the quality of AUR in general and especially as TU to advise
other people to do so too. Packaging a secure chat program and being so
lazy about https makes me wonder.

Also you do not need to move the packages as fast as possible into
community. I became TU month ago and arduino is still not in community
because some issues needed to be solved first. So quality and security
is more important here.

I think it'd be good for you to rethink the https (and gpg, hash) topic,
because (especially) as secure chat messenger packager it'd be extremely
important to me that you try to achieve the best security as possible.

~Nico



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Christian Rebischke]

On Wed, Nov 30, 2016 at 11:38:56PM +0100, Baptiste Jonglez wrote:
> 1) Would linux-mptcp [1] have its place in [community]?  From what I read
>about linux-zen and linux-grsec [2], there does not seem to be strong
>objections, especially since most (or even all?) third-party kernel
>modules now use DKMS.

Hello Baptiste, depends on the votes. As far i can see the package 
has 9 votes. It's not that much. I would wait for more votes or discuss
this with the community if another version of the linux kernel in the
official repositories is asked for.

> 2) Some dependencies of my packages are orphaned in [community], such as
>msgpack-c [3].  As a TU, I guess it would make sense to adopt them.

Yep, this would make sense.

> 3) ring-daemon requires non-released versions of restbed [4] and asio [5].
>Is it better to wait for upstream to release a version of these libs,
>or is it acceptable to package a snapshot in [community]?
> 
> Baptiste
> 
> [1] https://aur.archlinux.org/packages/linux-mptcp/
> [2] 
> https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html
> [3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/
> [4] https://aur.archlinux.org/packages/restbed-latest/
> [5] https://aur.archlinux.org/packages/asio-latest/

It is definitly better to wait for a stable upstream release. Please do
not push snapshots of git branches in community when you can avoid that.


Best regards

chris


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

On Tue, Nov 29, 2016 at 08:11:39PM +0100, Lukas Fleischer wrote:
> I confirm that I sponsor Baptiste.
> 
> I have worked with him several times in the past; among other things he
> contributed several patches to calcurse back in 2012 [1]. He is
> knowledgable and I think he will be a great addition to the team!
> 
> Let the discussion period begin!

Thanks Lukas!

There are some points that I feel could be worth discussing (besides TLS…):

1) Would linux-mptcp [1] have its place in [community]?  From what I read
   about linux-zen and linux-grsec [2], there does not seem to be strong
   objections, especially since most (or even all?) third-party kernel
   modules now use DKMS.

2) Some dependencies of my packages are orphaned in [community], such as
   msgpack-c [3].  As a TU, I guess it would make sense to adopt them.

3) ring-daemon requires non-released versions of restbed [4] and asio [5].
   Is it better to wait for upstream to release a version of these libs,
   or is it acceptable to package a snapshot in [community]?


Baptiste

[1] https://aur.archlinux.org/packages/linux-mptcp/
[2] https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html
[3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/
[4] https://aur.archlinux.org/packages/restbed-latest/
[5] https://aur.archlinux.org/packages/asio-latest/


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Lukas Fleischer]

On Mon, 28 Nov 2016 at 07:33:16, Baptiste Jonglez wrote:
> I would like to apply to become a TU.  Lukas Fleischer has kindly accepted
> to sponsor my application.

I confirm that I sponsor Baptiste.

I have worked with him several times in the past; among other things he
contributed several patches to calcurse back in 2012 [1]. He is
knowledgable and I think he will be a great addition to the team!

Let the discussion period begin!

[1] http://git.calcurse.org/calcurse.git/log/?qt=author=Baptiste+Jonglez


signature.asc
Description: signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Doug Newgard]

On Tue, 29 Nov 2016 12:08:39 +0100
Levente Polyak  wrote:

> On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
> > For a package in [community], an expired certificate for the upstream
> > tarball is not a big deal, since it does not directly affect the Arch user
> > installing the package.  As a packager, you can just get the tarball by
> > some other means, or wait a few days so that somebody renews the cert.
> > 
> > But for the AUR, an expired certificate would be annoying, as any user
> > trying to build the package (e.g. using an AUR helper) would encounter an
> > error.
> >   
> 
> I call bullshit, especially as your cases are purely about github!
> Surly, as if they can't wait "a few days" in such an unlikely scenario.
> And what if upstream forgets to pay for their servers, it won't be
> available too.
> How often do you think that certificates stay in an expired state. Of
> cause there may be one or two cases that could be named, its still
> certainly nothing to build upon.
> 
> 
> >> I never get why people always make such a big fuzz in not pulling over TLS.
> >> The same argumentation could be used for the regular tarballs and I
> >> repeat, the outcome is simple: use https, easy as that.  
> > 
> > Well, I agree with the outcome of the discussion, which was basically "One
> > way or the other does not change much security-wise, so let's switch to
> > HTTPS if doing so does not require significant efforts".
> >   
> 
> Fine, if you were already aware of the outcome, why this useless waste
> of time to discuss it yet again. Especially a TU applicant should follow
> chosen best practices and decisions. The AUR should not be any different
> from how they should be in the binary repos, so I expect to see those
> changes in your packages as well.

Git packages were not discussed, and https wasn't really "chosen best
practices", it was more "eh, why not". Getting all emotional because someone
doesn't buy into your reteric 100% isn't helping anyone.

> >>  
>  libringclient-git
>  - a VCS package should always provide its non-VCS package variant like
>    'libringclient'
>  - If there is no strong reason to depend on a git variant, always depend
>    on the non VCS, in this case ring-daemon instead of ring-daemon-git  
> >>>
> >>> See the above comment on gnome-ring-git.  
> >>
> >> And here is the -git hell I describes, either take all -git or none...
> >> that's not how it should be. Think how it would be if every library
> >> would be like that, that would mean you need to use -git for the whole
> >> system just because you switch a single package. Don't enforce it just
> >> because... if such happens people will figure.  
> > 
> > Again, the constraints are a bit different on the AUR and on a binary
> > repository.  What I try to ensure is that somebody running e.g. "yaourt -S
> > ring-gnome-git" will not have compilation issues.  If ring-gnome-git
> > depends on libringclient, then the former will not build if the API
> > provided by libringclient has changed recently.
> >   
> 
> Again, even through there are quite obviously no -git packages in the
> binary repository, the PKGBUILDs in the AUR should not be created in a
> different way then you would write them in the binary repo. Also AUR
> packages are influenced by each other and just completely abandon all
> provides is clearly a very bad practice. As easy as that.
> 
> https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html

Reality time: The AUR is different than the binary repos. Yes, ideally the
PKGBUILD should be able to go directly to the binary repos, but reality needs
to take precedence over blind ideology. AUR packages are managed differently
than repo packages and in the vast majority of cases are built differently as
well.

I agree with you in this case, but please don't use this dubious argument.

It does make sense to depend on the -git versions in cases like this as well.
We're not talking everything, we're talking everything in a given stack
provided by a single upstream. Applying this to another example, Qt5 packages
from git should depend on other Qt5 packages from git, not on their stable
versions.

Doug


pgpSgMvvIeLnj.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Eli Schwartz via aur-general]

On 11/28/2016 06:29 PM, Baptiste Jonglez wrote:
> On the other hand, if one day the TLS certificate becomes invalid (expired
> certificate, untrusted CA, etc), the package would fail to build.  I see
> this as a significant drawback of using git+https://.

When you say drawback, are you referring to TLS performing its intended
role?
I am really confused as to what you are trying to accomplish here.

I thought the whole point of switching to git+https:// is in order that
builds should fail when suspicious things happen to the source code,
like getting served from a domain with a very suspiciously broken
certificate.

The CACERT model assumes website owners are still alive and capable of
renewing their certificate before people call their customer service (if
applicable) number to complain that they can't access the website.
On the whole, it tends to be pretty successful. (Leaving aside peoples'
questions on the premise of the model, at least when we use it we use it
according to spec.)

An untrusted CA is, well, untrusted. Why would I want to build a package
authenticated by them, if I don't trust them?

Seriously, your argument is an argument against using TLS on the World
Wide Web. "I don't wanna use TLS, because now I cannot access all these
broken websites anymore!"

-- 
Eli Schwartz

Re: [aur-general] TU Application: Baptiste Jonglez

[georg]

Well, I actually withdraw this sentence, the discussion period is
pretty much about discussing :P


technically the discussion period has not even begun, since there was no 
confirmation of sponsorship yet.

g

Re: [aur-general] TU Application: Baptiste Jonglez

[Levente Polyak]

On November 29, 2016 12:08:39 PM GMT+01:00, Levente Polyak 
 wrote:
>Fine, if you were already aware of the outcome, why this useless waste
>of time to discuss it yet again.

Well, I actually withdraw this sentence, the discussion period is pretty much 
about discussing :P

Cheers, 
Levente 

Re: [aur-general] TU Application: Baptiste Jonglez

[Levente Polyak]

On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
> For a package in [community], an expired certificate for the upstream
> tarball is not a big deal, since it does not directly affect the Arch user
> installing the package.  As a packager, you can just get the tarball by
> some other means, or wait a few days so that somebody renews the cert.
> 
> But for the AUR, an expired certificate would be annoying, as any user
> trying to build the package (e.g. using an AUR helper) would encounter an
> error.
> 

I call bullshit, especially as your cases are purely about github!
Surly, as if they can't wait "a few days" in such an unlikely scenario.
And what if upstream forgets to pay for their servers, it won't be
available too.
How often do you think that certificates stay in an expired state. Of
cause there may be one or two cases that could be named, its still
certainly nothing to build upon.


>> I never get why people always make such a big fuzz in not pulling over TLS.
>> The same argumentation could be used for the regular tarballs and I
>> repeat, the outcome is simple: use https, easy as that.
> 
> Well, I agree with the outcome of the discussion, which was basically "One
> way or the other does not change much security-wise, so let's switch to
> HTTPS if doing so does not require significant efforts".
> 

Fine, if you were already aware of the outcome, why this useless waste
of time to discuss it yet again. Especially a TU applicant should follow
chosen best practices and decisions. The AUR should not be any different
from how they should be in the binary repos, so I expect to see those
changes in your packages as well.

>>
 libringclient-git
 - a VCS package should always provide its non-VCS package variant like
   'libringclient'
 - If there is no strong reason to depend on a git variant, always depend
   on the non VCS, in this case ring-daemon instead of ring-daemon-git
>>>
>>> See the above comment on gnome-ring-git.
>>
>> And here is the -git hell I describes, either take all -git or none...
>> that's not how it should be. Think how it would be if every library
>> would be like that, that would mean you need to use -git for the whole
>> system just because you switch a single package. Don't enforce it just
>> because... if such happens people will figure.
> 
> Again, the constraints are a bit different on the AUR and on a binary
> repository.  What I try to ensure is that somebody running e.g. "yaourt -S
> ring-gnome-git" will not have compilation issues.  If ring-gnome-git
> depends on libringclient, then the former will not build if the API
> provided by libringclient has changed recently.
> 

Again, even through there are quite obviously no -git packages in the
binary repository, the PKGBUILDs in the AUR should not be created in a
different way then you would write them in the binary repo. Also AUR
packages are influenced by each other and just completely abandon all
provides is clearly a very bad practice. As easy as that.

https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

On Tue, Nov 29, 2016 at 01:04:47AM +0100, Levente Polyak wrote:
> On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
> >> - you should use git+https:// instead of plain git:// even through the
> >>   CA world is a bit wonky it still authenticates the server and at the
> >>   very bare minimum adds confidentiality.
> > 
> > I don't like the "everything-over-HTTP(S)" approach in general, especially
> > when there is a dedicated protocol that works (yes, I know, this is basic 
> > ranting).
> > 
> > Assuming the git revision is identified by a commit hash, I see no value
> > in using HTTPS for authentication or verification.  I agree it is useful
> > however when building from a tag or a branch, as you correctly pointed out
> > for another package.
> > 
> > On the other hand, if one day the TLS certificate becomes invalid (expired
> > certificate, untrusted CA, etc), the package would fail to build.  I see
> > this as a significant drawback of using git+https://.
> 
> Well pulling over TLS was discussed over and over and over and over
> again and we ended up that we just do it for all of our packages if
> available...
> Thats why this came up in the first place:
> https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

Yes, I saw the discussion on arch-dev-public (but obviously could not
participate).

> I quote dave: "Security is not a binary thing".
> It adds another layer of security, if you like it or not. It
> authenticates the server (yes there may be untrusted CA, so? *shrug*)
> and i repeat again: at the very bare minimum adds confidentiality. Feel
> free to re-read the arch-dev-public thread, the outcome was the
> mentioned todo list.
> 
> I heard a lot of opinions and some of them are understandable... but
> saying that its a significant drawback as the certificate could possible
> be invalid/expired is certainly nothing i would _ever_ consider as such.

For a package in [community], an expired certificate for the upstream
tarball is not a big deal, since it does not directly affect the Arch user
installing the package.  As a packager, you can just get the tarball by
some other means, or wait a few days so that somebody renews the cert.

But for the AUR, an expired certificate would be annoying, as any user
trying to build the package (e.g. using an AUR helper) would encounter an
error.

> I never get why people always make such a big fuzz in not pulling over TLS.
> The same argumentation could be used for the regular tarballs and I
> repeat, the outcome is simple: use https, easy as that.

Well, I agree with the outcome of the discussion, which was basically "One
way or the other does not change much security-wise, so let's switch to
HTTPS if doing so does not require significant efforts".

> >> ring-gnome-git
> >> - a VCS package should always provide its non-VCS package variant like
> >>   'ring-gnome'
> > 
> > Actually, the missing "provides" is intended.  The Ring components are
> > interdependent and get updated quite frequently, so at any given time
> > `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
> > 
> > More practically, when the "provides" was here, I had issues with AUR
> > users mixing -git and non-git ring packages and complaining of building
> > errors.
> > 
> 
> This could be the case for literally _any_ library f.e. and still all of
> them have their corresponding provides. If there would be anything
> depending on ring-gnome you created an unresolvable hell be just
> conflicting it because it may have API changes.
> 
> 
> >> libringclient-git
> >> - a VCS package should always provide its non-VCS package variant like
> >>   'libringclient'
> >> - If there is no strong reason to depend on a git variant, always depend
> >>   on the non VCS, in this case ring-daemon instead of ring-daemon-git
> > 
> > See the above comment on gnome-ring-git.
> 
> And here is the -git hell I describes, either take all -git or none...
> that's not how it should be. Think how it would be if every library
> would be like that, that would mean you need to use -git for the whole
> system just because you switch a single package. Don't enforce it just
> because... if such happens people will figure.

Again, the constraints are a bit different on the AUR and on a binary
repository.  What I try to ensure is that somebody running e.g. "yaourt -S
ring-gnome-git" will not have compilation issues.  If ring-gnome-git
depends on libringclient, then the former will not build if the API
provided by libringclient has changed recently.

But you're right, it's a mess.  I updated the *ring*-git packages so that
they only depend on non-git packages, and they now all provide their
non-git version.

Anyway, I was thinking of orphaning all those -git Ring packages, since I
don't use them anymore and they take time to maintain.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Levente Polyak]

On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
>> - you should use git+https:// instead of plain git:// even through the
>>   CA world is a bit wonky it still authenticates the server and at the
>>   very bare minimum adds confidentiality.
> 
> I don't like the "everything-over-HTTP(S)" approach in general, especially
> when there is a dedicated protocol that works (yes, I know, this is basic 
> ranting).
> 
> Assuming the git revision is identified by a commit hash, I see no value
> in using HTTPS for authentication or verification.  I agree it is useful
> however when building from a tag or a branch, as you correctly pointed out
> for another package.
> 
> On the other hand, if one day the TLS certificate becomes invalid (expired
> certificate, untrusted CA, etc), the package would fail to build.  I see
> this as a significant drawback of using git+https://.
> 

Well pulling over TLS was discussed over and over and over and over
again and we ended up that we just do it for all of our packages if
available...
Thats why this came up in the first place:
https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

I quote dave: "Security is not a binary thing".
It adds another layer of security, if you like it or not. It
authenticates the server (yes there may be untrusted CA, so? *shrug*)
and i repeat again: at the very bare minimum adds confidentiality. Feel
free to re-read the arch-dev-public thread, the outcome was the
mentioned todo list.

I heard a lot of opinions and some of them are understandable... but
saying that its a significant drawback as the certificate could possible
be invalid/expired is certainly nothing i would _ever_ consider as such.
I never get why people always make such a big fuzz in not pulling over TLS.
The same argumentation could be used for the regular tarballs and I
repeat, the outcome is simple: use https, easy as that.


>> ring-gnome-git
>> - a VCS package should always provide its non-VCS package variant like
>>   'ring-gnome'
> 
> Actually, the missing "provides" is intended.  The Ring components are
> interdependent and get updated quite frequently, so at any given time
> `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
> 
> More practically, when the "provides" was here, I had issues with AUR
> users mixing -git and non-git ring packages and complaining of building
> errors.
> 

This could be the case for literally _any_ library f.e. and still all of
them have their corresponding provides. If there would be anything
depending on ring-gnome you created an unresolvable hell be just
conflicting it because it may have API changes.


>> libringclient-git
>> - a VCS package should always provide its non-VCS package variant like
>>   'libringclient'
>> - If there is no strong reason to depend on a git variant, always depend
>>   on the non VCS, in this case ring-daemon instead of ring-daemon-git
> 
> See the above comment on gnome-ring-git.

And here is the -git hell I describes, either take all -git or none...
that's not how it should be. Think how it would be if every library
would be like that, that would mean you need to use -git for the whole
system just because you switch a single package. Don't enforce it just
because... if such happens people will figure.


cheers,
Levente




signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hi,

On Mon, Nov 28, 2016 at 12:20:40PM +0100, Levente Polyak wrote:
> > Don't hesitate if you have any questions, or comments on my AUR packages!
> 
> Sure, I always take a look at all packages of an applicant and suggest
> changes before I decide how to vote... so here we go :P

Yes, I was expecting this :)

> pjproject
> - if you must use -j1 for every make call, you can simply add
>   !makeflags to the options instead.

Good catch, this was actually copied unchanged from the pjproject package
.

I just tested building in parallel on a 16-core machine, and it works
fine, so I removed the -j1.  The original issue must have been fixed
upstream.

> linux-mptcp
> - #tag= should never be used for git packages, instead store the commit
>   hash for the tag and always use the #tag= prefix. A named tag does not
>   mean much and you won't even notice when upstream changes such.
>   This is especially bad when using plain git:// :-)

Interesting, I had never thought about this issue.

I think I will switch to a tarball as suggested by Eli, I didn't know that
github provides tarballs for each commit.  The downside is that $pkgver
will no longer be computed automatically, I will have to update it
manually.

> - You should add an initramfs post transaction hook like in the regular
>   kernel [0] to avoid problems like described in #51818.

Thanks for the hint, will do.

> ring-daemon:
> - just a feeling but a description with 202 chars feels quite long :P

Is there a hard limit somewhere, maybe in the AUR?

Anyway, upstream has changed its description to a shorter one, so I used
that instead.  It's now "only" 130 chars.

> - you should use git+https:// instead of plain git:// even through the
>   CA world is a bit wonky it still authenticates the server and at the
>   very bare minimum adds confidentiality.

I don't like the "everything-over-HTTP(S)" approach in general, especially
when there is a dedicated protocol that works (yes, I know, this is basic 
ranting).

Assuming the git revision is identified by a commit hash, I see no value
in using HTTPS for authentication or verification.  I agree it is useful
however when building from a tag or a branch, as you correctly pointed out
for another package.

On the other hand, if one day the TLS certificate becomes invalid (expired
certificate, untrusted CA, etc), the package would fail to build.  I see
this as a significant drawback of using git+https://.

> pius
> - documentation, or hint to documentations inside .install files always
>   feels like the wrong place. If there is documentation in
>   /usr/share/doc/pius then people will find it.

I generally agree with this.  In this case, however, the suggested
configuration option is really needed on Arch when using the new Gnupg key
format, and this is not explicitely documented upstream.

I think I will send a patch upstream to fix the issue (auto-detect the
keyring format) and remove the .install file altogether with the next
release.

> ring-gnome-git
> - a VCS package should always provide its non-VCS package variant like
>   'ring-gnome'

Actually, the missing "provides" is intended.  The Ring components are
interdependent and get updated quite frequently, so at any given time
`ring-foo` and `ring-foo-git` are likely offer a different API/ABI.

More practically, when the "provides" was here, I had issues with AUR
users mixing -git and non-git ring packages and complaining of building
errors.

> libringclient-git
> - a VCS package should always provide its non-VCS package variant like
>   'libringclient'
> - If there is no strong reason to depend on a git variant, always depend
>   on the non VCS, in this case ring-daemon instead of ring-daemon-git

See the above comment on gnome-ring-git.

> - the pkgver() function doesn't sound specific enough, it just returns
>   a simple date without anything else (f.e. 20161110) which means
>   building on the same date can result in the same package version while
>   being built from quite different source states.

Good point, I can switch to the `git describe` method used by most of my
other git packages.

> udrawgraph
> - just a bit of style, but we have arch specific depends like
>   depends_x86_64 which looks better :P

Fixed.  This package long predates arch-specific depends.

> tsocks-ipv6
> - this looks like it should also provide tsocks as it just adds
>   additional v6 support

Indeed, fixed.

> coq-doc
> - the sources must be prefixed with the version as otherwise older
>   tarballs will "conflict". on top of that "stdlib.tar.gz" sounds
>   a bit too generic and may overlap with another package, conisder
>   also including the package name into the prefix to avoid such
>   situation.

Fixed.

> - sources that are not unique (like "/v$pkgver.tar.gz" from github)
>   should be prefixed with the package name (+ of cause pkgver) to
>   be unique. This is important if you configures shared SRCDEST to
>   avoid conflicts.

Re: [aur-general] TU Application: Baptiste Jonglez

[Eli Schwartz via aur-general]

On 11/28/2016 11:26 AM, Levente Polyak wrote:
> When using a commit hash you gain basically two things out of the box:
> - get aware if wonky upstream changes something
> - get an integrity value that a potential attacker must defeat, which
>   not be the easiest task for a full commit hash (for a short partial
>   hash there are of cause some PoC's/tools available)

Hmm, that is true. git has builtin integrity checks but also ends up
almost completely lacking in any capacity for authentication. At least
as far as makepkg is concerned.

As a user, I think I would still prefer tarballs rather than unnecessary
git history... but if you must use git for non-VCS packages then commit
hashes are useful.

> In fact we already had several discussions in the IRC about this topic
> and what I mentioned above was always sufficient to justify getting rid
> of it. The only reason we don't yet have a TODO list to switch away from
> #tag= is simply lack of time (but its still on my todo list besides
> getting a TODO list for git:// sources).
> 
> If a remember correctly either heftig or JGC has created a convenience
> script to update a PKGBUILDs values, maybe they share it with us :)

That is very interesting information, thanks for mentioning it. My
curiosity is now sated. :)

>>> net-tools-mptcp
>>> - #branch= should never be used for non VCS git packages, instead store
>>>   the commit hash for the tag and always use the #tag= prefix. A named
>>>   branch does not mean much and you won't even notice when upstream
>>>   changes or adds commits to such.
>>
>> It has a pkgver() function which generates a VCS-style pkgver, and draws
>> from a #branch= so actually it is a VCS git package. The problem is that
>> it doesn't say so in the pkgname. :p
>>
> 
> Well yes... and no... though the same while looking at it but at the end
> I'm not quite sure what the intention of Baptiste is. As the branch used
> is a simple version identifier, I assumed he pretty much wanted to have
> a static versioned package.
> pkgver() itself does not tell us which one it should be, if you have a
> static version package that pulls from a git commit hash you can have a
> pkgver() function for convenience.

I have noticed that trick in repo packages, yeah. But this is pulling
from a branch... anything that has changing sources would be VCS, except
that without both #branch= and a pkgver() it is merely broken beyond repair.

Now, while some projects do use versioned branches to separate
development on apparently incompatible release branches, it could be
that this upstream only commits to that branch when releasing, and
otherwise it will never get new commits (so it is a static versioning
branch, and the tag itself wasn't used for inexplicable reasons which
justify themselves because "because"). I couldn't be bothered to read
the PKGBUILD *and* check the upstream sources, just to make random
comments about style. :p
(If so, why does the pkgver function specifically use `git describe
--long` when `git describe` would by default exclude
"r0.guselesshashpointingtoatag"` ???)

But either way, you said "you won't even notice when upstream changes or
adds commits to such" and the *current* pkgver function guarantees he
*will* notice.

-- 
Eli Schwartz

Re: [aur-general] TU Application: Baptiste Jonglez

[Levente Polyak]

On 11/28/2016 05:05 PM, Eli Schwartz via aur-general wrote:
> On 11/28/2016 06:20 AM, Levente Polyak wrote:
>> - #tag= should never be used for git packages, instead store the commit
>>   hash for the tag and always use the #tag= prefix.
> 
> Typo?
> 

uuups, you caught me :P My bad! Of cause this should be #commit=
Thanks Eli!

>>   A named tag does not mean much and you won't even notice when upstream
>>   changes such. This is especially bad when using plain git:// :-)
> 
> Well, I should hope upstream doesn't re-release their tags... if so, you
> might have other problems.

Well I already encountered a re-release at least twice, shame on them!
When using a commit hash you gain basically two things out of the box:
- get aware if wonky upstream changes something
- get an integrity value that a potential attacker must defeat, which
  not be the easiest task for a full commit hash (for a short partial
  hash there are of cause some PoC's/tools available)

> But from the repo PKGBUILDs I have seen, it seems to me as though there
> is no policy whatsoever... some devs do like you suggest, other devs are
> more than happy to use "#tag=$pkgver".

Well i assume "more happy" just means "able to be more lazy" (without
any offense to anyone!) :P

In fact we already had several discussions in the IRC about this topic
and what I mentioned above was always sufficient to justify getting rid
of it. The only reason we don't yet have a TODO list to switch away from
#tag= is simply lack of time (but its still on my todo list besides
getting a TODO list for git:// sources).

If a remember correctly either heftig or JGC has created a convenience
script to update a PKGBUILDs values, maybe they share it with us :)

> 
>> udrawgraph
>> - just a bit of style, but we have arch specific depends like
>>   depends_x86_64 which looks better :P
> 
> That isn't "style", that is something that *must* be done, for practical
> purposes. makepkg --printsrcinfo relies on arch-dependent variables that
> are *always* there, in order to actually print truthful values. Also,
> arch-dependent sources done properly will allow updpkgsums to properly
> update, rather than merging the local *sums_$CARCH into the main
> checksums array.
> 
> All that matters a lot in the AUR, which depends on .SRCINFO, even if it
> doesn't matter so much in the repos which depend on the metadata in a
> built package.
> 

Fair enough... that's a pretty good point why it should be mandatory.
Did not really take the .SRCINFO into account for this particular case.

>> net-tools-mptcp
>> - #branch= should never be used for non VCS git packages, instead store
>>   the commit hash for the tag and always use the #tag= prefix. A named
>>   branch does not mean much and you won't even notice when upstream
>>   changes or adds commits to such.
> 
> It has a pkgver() function which generates a VCS-style pkgver, and draws
> from a #branch= so actually it is a VCS git package. The problem is that
> it doesn't say so in the pkgname. :p
> 

Well yes... and no... though the same while looking at it but at the end
I'm not quite sure what the intention of Baptiste is. As the branch used
is a simple version identifier, I assumed he pretty much wanted to have
a static versioned package.
pkgver() itself does not tell us which one it should be, if you have a
static version package that pulls from a git commit hash you can have a
pkgver() function for convenience.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Eli Schwartz via aur-general]

On 11/28/2016 06:20 AM, Levente Polyak wrote:
> linux-mptcp
> - you should use git+https:// instead of plain git:// even through the
>   CA world is a bit wonky it still authenticates the server and at the
>   very bare minimum adds confidentiality.

Now that you mention it, this does seem rather obvious... maybe I should
switch my own AUR packages to do this. It is just as fast, so there is
no real downside.

Now I'm glad I read these threads!

> - #tag= should never be used for git packages, instead store the commit
>   hash for the tag and always use the #tag= prefix.

Typo?

>   A named tag does not mean much and you won't even notice when upstream
>   changes such. This is especially bad when using plain git:// :-)

Well, I should hope upstream doesn't re-release their tags... if so, you
might have other problems.

Anyway, I would instead suggest that there is no need to pull the source
code for stable releases via git (which for long-lived projects like the
Linux kernel means a *lot* of history to download).
I can barely understand that, in the case of e.g. systemd which uses git
to backport commits. Although really, github allows you to download a
commit as a patch file...
I usually only see that in repo PKGBUILDs. I guess since the devs are
usually the only ones building the package, and the dev keeps the clone
around, it "doesn't matter" that hypothetical others would have to clone
all that history?

But from the repo PKGBUILDs I have seen, it seems to me as though there
is no policy whatsoever... some devs do like you suggest, other devs are
more than happy to use "#tag=$pkgver".

> udrawgraph
> - just a bit of style, but we have arch specific depends like
>   depends_x86_64 which looks better :P

That isn't "style", that is something that *must* be done, for practical
purposes. makepkg --printsrcinfo relies on arch-dependent variables that
are *always* there, in order to actually print truthful values. Also,
arch-dependent sources done properly will allow updpkgsums to properly
update, rather than merging the local *sums_$CARCH into the main
checksums array.

All that matters a lot in the AUR, which depends on .SRCINFO, even if it
doesn't matter so much in the repos which depend on the metadata in a
built package.

> net-tools-mptcp
> - #branch= should never be used for non VCS git packages, instead store
>   the commit hash for the tag and always use the #tag= prefix. A named
>   branch does not mean much and you won't even notice when upstream
>   changes or adds commits to such.

It has a pkgver() function which generates a VCS-style pkgver, and draws
from a #branch= so actually it is a VCS git package. The problem is that
it doesn't say so in the pkgname. :p

-- 
Eli Schwartz

Re: [aur-general] TU Application: Baptiste Jonglez

[Levente Polyak]

Hi Bapiste,

> 
> Don't hesitate if you have any questions, or comments on my AUR packages!
> 

Sure, I always take a look at all packages of an applicant and suggest
changes before I decide how to vote... so here we go :P
Excuse me if I copy-paste some blocks, its just simpler doing so :)


ring-daemon:
- just a feeling but a description with 202 chars feels quite long :P

opendht:
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

sig2dot
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.

pjproject
- if you must use -j1 for every make call, you can simply add
  !makeflags to the options instead.

opendht-git
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

pius
- documentation, or hint to documentations inside .install files always
  feels like the wrong place. If there is documentation in
  /usr/share/doc/pius then people will find it.

linux-mptcp
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.
- #tag= should never be used for git packages, instead store the commit
  hash for the tag and always use the #tag= prefix. A named tag does not
  mean much and you won't even notice when upstream changes such.
  This is especially bad when using plain git:// :-)
- You should add an initramfs post transaction hook like in the regular
  kernel [0] to avoid problems like described in #51818.

coq-doc
- the sources must be prefixed with the version as otherwise older
  tarballs will "conflict". on top of that "stdlib.tar.gz" sounds
  a bit too generic and may overlap with another package, conisder
  also including the package name into the prefix to avoid such
  situation.

asio-latest
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.

ring-gnome-git
- a VCS package should always provide its non-VCS package variant like
  'ring-gnome'
- the pkgver() function doesn't sound specific enough, it just returns
  a simple date without anything else (f.e. 20161110) which means
  building on the same date can result in the same package version while
  being built from quite different source states.

restbed-latest
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

restbed
- #tag= should never be used for git packages, instead store the commit
  hash for the tag and always use the #tag= prefix. A named tag does not
  mean much and you won't even notice when upstream changes such.

kashmir
- you should use git+https:// instead of plain git:// even through the
  CA world is a bit wonky it still authenticates the server and at the
  very bare minimum adds confidentiality.

udrawgraph
- just a bit of style, but we have arch specific depends like
  depends_x86_64 which looks better :P
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.
- every reference to $srcdir should be put inside double-quotes in case
  it contains spaces.

ring-daemon-git
- a VCS package should always provide/conflicts its non-VCS package
  variant like 'ring-daemon'
- just a feeling but a description with 202 chars feels quite long :P
- the pkgver() function doesn't sound specific enough, it just returns
  a simple date without anything else (f.e. 20161110) which means
  building on the same date can result in the same package version while
  being built from quite different source states.

libringclient-git
- a VCS package should always provide its non-VCS package variant like
  'libringclient'
- If there is no strong reason to depend on a git variant, always depend
  on the non VCS, in this case ring-daemon instead of ring-daemon-git
- the pkgver() function doesn't sound specific enough, it just returns
  a simple date without anything else (f.e. 20161110) which means
  building on the same date can result in the same package version while
  being built from quite different source states.

npiet
- every reference to $pkgdir should be put inside double-quotes in case
  it contains spaces.

tsocks-ipv6
- this looks like it should also provide tsocks as it just adds
  additional v6 support

iproute-mptcp
- sources that are not unique (like "/v$pkgver.tar.gz" from github)
  should be prefixed with the package name (+ of cause pkgver) to
  be unique. This is important if you configures shared SRCDEST to
  avoid 

[aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hello,

I would like to apply to become a TU.  Lukas Fleischer has kindly accepted
to sponsor my application.

I am currently a PhD student in France, doing research on networking.  I
am also involved in several projects, in particular DIY ISPs [1], the FDN
Federation in France [2], OpenWRT/LEDE [3], etc.  The common motivation is
to work towards a more open and decentralised Internet.

I have been using Arch Linux on my personal laptops since around 2010.
I think I have never had to reinstall Arch Linux on my main laptop since
then!  In the past, I was also running Arch Linux on my servers, but I
since switched to Debian for all my servers.

By the way, I am not very active on the mailing lists, but I read most
threads on aur-general and arch-dev-public.

In the AUR, I maintain 33 packages [4], of which the most noteworthy are:

- ring: a secure and distributed voice/video/chat communication software
  (Ring is the successor of SFLphone, basically using a DHT to find
  contacts instead of relying on SIP servers, and tons of other
  improvements)

- coq: a formal proof assistant written in Ocaml

- linux-mptcp: the linux kernel with support for Multipath TCP, from
  Université Catholique de Louvain

The other packages I maintain are either dependencies of the above, or
small software tools that I packaged when I needed them.  I regularly use
about 2/3 of these packages, but I still try to maintain the other ones.

I mostly want to become a TU to push ring, coq and linux-mptcp to the
[community] binary repository.  These packages all take a fairly long time
to build, and additionally the Ring packages are a dependency nightmare.
It is often necessary for users to rebuild all dependencies simultaneously
because of API/ABI changes, and this is impractical and time-consuming
when using the AUR, especially given the number of dependencies.

Regarding linux-mptcp, it is not popular enough at the moment, and there
are few kernel packages in binary repositories.  I would wait for the
package to obtain 10 votes (and confirmation that another kernel package
is indeed welcome in the repositories) before pushing it to [community].

As a final note, I am already using the devtools to test-build my AUR
packages in clean chroots on a server.  This provides some form of
"continuous integration" of my AUR packages, although it is not completely
satisfying right now.

Don't hesitate if you have any questions, or comments on my AUR packages!

Baptiste

[1] https://diyisp.org/dokuwiki/doku.php
[2] https://www.ffdn.org/en
[3] https://lede-project.org/
[4] https://aur.archlinux.org/packages/?O=0=m=zorun=v=d


signature.asc
Description: PGP signature