Hello everybody,
As gnupg 2.1.13 is now available in core I'd like to update monkeysphere to 0.38, here are the PKGBUILDs for monkeysphere[2] and for agent-transfer[1], a new monkeysphere checkdependency.
Agent-transfer is included in the monkeysphere source code but it's a checkdependency and so I choose to create a separate package for it, is it correct? How can I make it better?
Namcap will complain about monkeysphere dependencies as it thinks they are not needed but they actually are
Thanks
sValo
[1] https://git.eigenlab.org/svalo/agent-transfer/blob/0.38/PKGBUILD
[2] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/PKGBUILD
Hi Valo,
On Wed, Jun 22, 2016 at 11:30:57AM +0200, Valo wrote:
As gnupg 2.1.13 is now available in core I'd like to update monkeysphere to 0.38, here are the PKGBUILDs for monkeysphere[2] and for agent-transfer[1], a new monkeysphere checkdependency.
Agent-transfer is included in the monkeysphere source code but it's a checkdependency and so I choose to create a separate package for it, is it correct? How can I make it better?
Do you think that agent-transfer is a useful package in its own right? That is, can it be used and be useful without monkeysphere? If so, it could make sense to provide it as a separate package, but I think you should implement it as a split package then (since both monkeysphere and agent-transfer "build" from the same source).
Of course, to avoid over-engineering, you could just have a single package bundling both monkeysphere and agent-transfer. Judging from [2], this is what is intended by upstream.
Also, some minor nitpicks:
- you have a small typo in agent-transfer ("makedepens")
- the "gcc" makedepends is not needed, because it is in base-devel [1]
- as you have apparently figured out, installing in /usr/sbin/ is not recommended [3], but I don't think it's worth patching the source [4]. /usr/sbin is a symbolic link to /usr/bin anyway.
- I'm not sure about the convention for adding users/groups [5]. Looking at a few packages [6,7,8], it seems that UID and GID are hard-coded, but I don't know if there is a registry. At the very least, you should create a system user (-r option to useradd), because otherwise the UID will fall into the user range 1000+.
Thanks for maintaining the package! Baptiste
[1] https://wiki.archlinux.org/index.php/PKGBUILD#makedepends [2] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/exclude-agent.patch [3] https://wiki.archlinux.org/index.php/Arch_packaging_standards#Directories [4] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/binmerge.patch [5] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/monkeysphere.install [6] https://git.archlinux.org/svntogit/packages.git/tree/trunk/ntp.install?h=pac... [7] https://git.archlinux.org/svntogit/community.git/tree/trunk/tor.install?h=pa... [8] https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=package...
Hi Baptiste,
Il 22/06/2016 12:12, Baptiste Jonglez ha scritto:
That is, can it be used and be useful without monkeysphere? If so, it could make sense to provide it as a separate package,
As for package description: "|Copy a secret key from GnuPG's gpg-agent to OpenSSH's ssh-agent|"
It *can* be used outsite of monkeysphere but I don't know if it *will* :)
but I think you should implement it as a split package then (since both monkeysphere and agent-transfer "build" from the same source).
I thought about it but I wasn't able to understand from the wiki how I should proceed aside from the array of package names, can you point me to a good PKGBUILD I cant learn from?
Of course, to avoid over-engineering, you could just have a single package bundling both monkeysphere and agent-transfer. Judging from [2], this is what is intended by upstream.
Yup, I thought it as well but couldn't figure out how to resolve the checkdependency on agent-transfer of monkeysphere without packaging it on it's own. As the software is about security I feel like running the tests upstream provide is very important and during the tests agent-transfer is called, without it tests will not succeed.
Also, some minor nitpicks:
you have a small typo in agent-transfer ("makedepens")
the "gcc" makedepends is not needed, because it is in base-devel [1]
Right, removed :)
- as you have apparently figured out, installing in /usr/sbin/ is not recommended [3], but I don't think it's worth patching the source [4]. /usr/sbin is a symbolic link to /usr/bin anyway.
Ok, it was so when I adopted the package and kept it, if it's compliant with the standards then I'll remove it happily
- I'm not sure about the convention for adding users/groups [5]. Looking at a few packages [6,7,8], it seems that UID and GID are hard-coded, but I don't know if there is a registry. At the very least, you should create a system user (-r option to useradd), because otherwise the UID will fall into the user range 1000+.
Great! I'll add the -r option as I don't feel like hardcoding a UID and GID.
Thanks for maintaining the package!
Thanks for the feedback!
sValo
For creating users, there is now sysusers.d which makes system user creation a bit more standardised, take a look here: https://www.freedesktop.org/software/systemd/man/sysusers.d.html
Regards, Justin
Hello,
Il 22/06/2016 23:39, Justin Dray ha scritto:
For creating users, there is now sysusers.d which makes system user creation a bit more standardised, take a look here: https://www.freedesktop.org/software/systemd/man/sysusers.d.html
Regards, Justin
Interesting, I didn't know it, thanks for pointing it out but as monkeysphere user needs a shell I think I'll stick to useradd -r.
Il 23/06/2016 01:13, Doug Newgard ha scritto:
In addition to everything else mentioned, you should never be running chown in the install scripts. If the files/dirs need to be owned by a specific user/group, you should do that in the package function.
Ok, moved in the package function
You can't really use $pkgdir in the build function.
Yes, it makes no sense, don't know why I put it there.
Please, for the sake of readability, be consistent with how you use variables. Either use braces or don't.
Fixed
Thanks everyone for the feedback, I pushed the packages to the aur, I'll be happy to receive further suggestions :)
sValo
On Wed, Jun 22, 2016 at 02:47:09PM +0200, Valo wrote:
Il 22/06/2016 12:12, Baptiste Jonglez ha scritto:
That is, can it be used and be useful without monkeysphere? If so, it could make sense to provide it as a separate package,
As for package description: "|Copy a secret key from GnuPG's gpg-agent to OpenSSH's ssh-agent|"
It *can* be used outsite of monkeysphere but I don't know if it *will* :)
but I think you should implement it as a split package then (since both monkeysphere and agent-transfer "build" from the same source).
I thought about it but I wasn't able to understand from the wiki how I should proceed aside from the array of package names, can you point me to a good PKGBUILD I cant learn from?
Look at "man PKGBUILD", section "PACKAGE SPLITTING"
Of course, to avoid over-engineering, you could just have a single package bundling both monkeysphere and agent-transfer. Judging from [2], this is what is intended by upstream.
Yup, I thought it as well but couldn't figure out how to resolve the checkdependency on agent-transfer of monkeysphere without packaging it on it's own. As the software is about security I feel like running the tests upstream provide is very important and during the tests agent-transfer is called, without it tests will not succeed.
Ah, ok, I misunderstood your problem. So, the split package idea will definitely not help, because build() and check() are called before running package_foo() and installing the packages. This means that agent-transfer will not be available in $PATH.
- I'm not sure about the convention for adding users/groups [5]. Looking at a few packages [6,7,8], it seems that UID and GID are hard-coded, but I don't know if there is a registry. At the very least, you should create a system user (-r option to useradd), because otherwise the UID will fall into the user range 1000+.
Great! I'll add the -r option as I don't feel like hardcoding a UID and GID.
Yes, I don't think there actually is a convention for this.
That being said, don't you think you should remove the user/group when uninstalling the package?
https://aur.archlinux.org/cgit/aur.git/tree/monkeysphere.install?h=monkeysph...
Baptiste
Hello
Il 2-5/06/2016 19:41, Baptiste Jonglez ha scritto:
Ah, ok, I misunderstood your problem. So, the split package idea will definitely not help, because build() and check() are called before running package_foo() and installing the packages. This means that agent-transfer will not be available in $PATH.
Yup, I checked and under Debian they have 2 distinct packages [2], so we do now :)
That being said, don't you think you should remove the user/group when uninstalling the package?
This is a point I was dubtful about: in the debian package the post-remove script takes care of checking if monkeysphere is used in the sshd_config file, if not then deletes user and group as well as their directories.
When I tried to delete user and group I received a warning about some processes (ssh-agent and gpg-agent) using some files belonging to monkeysphere, to remove them I would have had to force the removal but not knowing what's going on on the user's computer made me rethink about it.
Another argument is that if, for any reason, the check on the sshd_config file results in a fake negative match about monkeysphere being in use, the user can then be locked outside of his/her own server which is a thing nobody likes :)
Another reason which is more personal is that I do think it's the user's decision whether it's time to remove the user or not based on his/her own configuration and because of this I put the message [1]
All the considerations above assume that I should remove the files as well, I can remove the user without touching the files and informing the user he/she has to take care of it. I can try to remove the user without -f an fail with a message otherwise.
Can this be a good solution?
It seems to me that there are no general guidelines about packages managing users, am I wrong? Should someone with a deeper knowledge than mine write something down on the wiki?
Again thanks for the suggestions :)
sValo
[1]https://aur.archlinux.org/cgit/aur.git/tree/monkeysphere.install?h=monkeysph...
On Wed, 22 Jun 2016 12:12:00 +0200 Baptiste Jonglez baptiste@bitsofnetworks.org wrote:
- as you have apparently figured out, installing in /usr/sbin/ is not recommended [3], but I don't think it's worth patching the source [4]. /usr/sbin is a symbolic link to /usr/bin anyway.
This isn't entirely correct. Pacman will no longer parse symlinks, so the patch is necessary or the package won't install. I would use sed instead of a patch, but that's more of a personal preference.
On Wed, 22 Jun 2016 11:30:57 +0200 Valo valo@autoproduzioni.net wrote:
Hello everybody,
As gnupg 2.1.13 is now available in core I'd like to update monkeysphere to 0.38, here are the PKGBUILDs for monkeysphere[2] and for agent-transfer[1], a new monkeysphere checkdependency.
Agent-transfer is included in the monkeysphere source code but it's a checkdependency and so I choose to create a separate package for it, is it correct? How can I make it better?
Namcap will complain about monkeysphere dependencies as it thinks they are not needed but they actually are
Thanks
sValo
[1] https://git.eigenlab.org/svalo/agent-transfer/blob/0.38/PKGBUILD
[2] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/PKGBUILD
In addition to everything else mentioned, you should never be running chown in the install scripts. If the files/dirs need to be owned by a specific user/group, you should do that in the package function.
You can't really use $pkgdir in the build function.
Please, for the sake of readability, be consistent with how you use variables. Either use braces or don't.
Den 23-06-2016 kl. 01:13 skrev Doug Newgard:
In addition to everything else mentioned, you should never be running chown in the install scripts. If the files/dirs need to be owned by a specific user/group, you should do that in the package function.
How is one supposed to do this if they're not hardcoding the uid/gid? (Ie., the uid/gid won't be known until `adduser` has been run in the .install script. See Message-Id: 4e51998e-e14e-5f3a-b825-242d96d08cad@autoproduzioni.net)
On Wed, 29 Jun 2016 00:18:59 +0200 Frederik “Freso” S. Olesen archlinux@freso.dk wrote:
Den 23-06-2016 kl. 01:13 skrev Doug Newgard:
In addition to everything else mentioned, you should never be running chown in the install scripts. If the files/dirs need to be owned by a specific user/group, you should do that in the package function.
How is one supposed to do this if they're not hardcoding the uid/gid? (Ie., the uid/gid won't be known until `adduser` has been run in the .install script. See Message-Id: 4e51998e-e14e-5f3a-b825-242d96d08cad@autoproduzioni.net)
If files or dirs need to be owned by the user/group in question, the uid/gid need to be hard coded.
That's not he case here, though.
aur-general@lists.archlinux.org