[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161129/4820d17f/attachment-0001.asc>