[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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161129/b089cce0/attachment.asc>