Package Details: libnitrokey 3.4.1-1

Git Clone URL: https://aur.archlinux.org/libnitrokey.git (read-only)
Package Base: libnitrokey
Description: Communicate with Nitrokey stick devices in a clean and easy manner
Upstream URL: https://www.nitrokey.com
Licenses: LGPL3
Submitter: milouse
Maintainer: milouse
Last Packager: milouse
Votes: 4
Popularity: 0.063561
First Submitted: 2017-10-12 19:27
Last Updated: 2018-08-21 12:30

Dependencies (3)

Required by (1)

Sources (1)

Latest Comments

milouse commented on 2018-06-18 08:06

Good idea! I'll look at it as soon as I've some time for me this week.

dude42 commented on 2018-06-16 01:56

Ah thanks I see now. Yes I guess most people would feel more comfortable building directly from the source than trusting binaries, signed or not.

By the way, it is possible to check out the git repo directly for a specified tag in the PKGBUILD instead of trusting a tar.gz file provided. Signal is an example of an AUR package that does this. Perhaps this is a reasonable alternative to signature validation on their provided tar.gz files ?

milouse commented on 2018-06-15 10:00

Hi dude42,

Thanks for the exemple of gpg signature verification. I'll look at it ASAP.

Regarding package difference, it's because you download the package specially uploaded by Nitrokey (i.e. the « libnitrokey-3.3.tar.gz » link on the release page¹), while I use the auto-generated link of github in my package (i.e. the « Source code (tar.gz) » link on the release page¹).

For a reason I cannot exlain (because I don't take time to understand yet), these 2 packages are different (maybe Nitrokey add some other stuff in their tarball… I don't know.

The debate is open: should we « blindly » trust a package pushed by Nitrokey without knowing what's in the box, even if they give us a gpg signature to check our download, OR should we only trust the source code publicly auditable on github, but without any mean of control over what we download?

Either we have to trust github to give us the same content as we have on the git repository AND our FAI or any other organisation, which may be able to interfere during the download, OR we have to trust Nitrokey to not have add suspicious stuff in their gpg checkable package.

¹ https://github.com/Nitrokey/libnitrokey/releases/tag/v3.3

dude42 commented on 2018-06-15 01:21

BTW usbguard-nox is an example of a package that uses gpg signature validation in the PKGBUILD.

dude42 commented on 2018-06-15 01:10

Hi there,

Could you please add gpg signature verification to this package and the nitrokey-app package ?

The release key fingerprint can be found here:

https://www.nitrokey.com/download

and here:

https://github.com/Nitrokey/nitrokey-app/releases

I am also going to paste the fingerprint I see here for additional verification:

868184069239FF65DE0BCD7D D9BAE35991DE5B22

I have a concern - I downloaded the tar.gz and the tar.gz.sig directly from (why does the PKGBUILD use a different URL ?):

https://github.com/Nitrokey/libnitrokey/releases/download/v3.3/libnitrokey-3.3.tar.gz

and

https://github.com/Nitrokey/libnitrokey/releases/download/v3.3/libnitrokey-3.3.tar.gz.sig

The gpg signature verification for these two files succeeded.

However, when I then run makepkg with these downloaded files the sha256sum validation for the hash in the PKGBUILD fails.

It would be weird if the URL in the PKGBUILD provided a different binary from the URLs I used.

Any ideas ?

Thanks.

Arvedui commented on 2018-04-23 08:25

Yes! Thank you!

milouse commented on 2018-04-23 08:16

It should be ok now ?

Arvedui commented on 2018-04-22 15:48

Sorry it seems i forgot to mention the most important bit …

Since your change did not change the resulting file name, it just makes explicit what was derived from the url, it does not solve the problem I have.

What I meant was, that the file name should be set to something unique like "libnitrokey-3.3.tar.gz".

milouse commented on 2018-04-13 15:54

Oh, I didn't know you can do this kind of stuff (using another makepkg source folder). I'll fix this asap, sorry for that.

Arvedui commented on 2018-04-13 13:54

Please set an explicit name for the tar file from github. Currently it potentially breaks, and it just did for me, when using a common source folder with makepkg.