Re: [gentoo-dev] Sanity check: enewuser in binpkg with portage-utils
On 2017-07-20 19:17, Michał Górny wrote: > No. This is entirely wrong and insane. Tar stores user and group > names, and restores them correctly. Oops, thanks for correction. -- Regards, Thomas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sanity check: enewuser in binpkg with portage-utils
Dnia 20 lipca 2017 18:15:00 CEST, Thomas Deutschmann napisał(a): >Hi, > >keep in mind that when installing a binpkg, src_* functions are >skipped, >see https://devmanual.gentoo.org/ebuild-writing/functions/ > >So when you are doing anything with the actual user, you have to do >that >in a pkg_* function. > >In case of "exeopts", if you do something like > > exeopts -m 6710 -g plgudev > >in any src_* function, the created image will use the GID/UIDs from the >system used to create the binpkg. This is probably your problem... > >Make sure to adjust permissions in pkg_* functions! No. This is entirely wrong and insane. Tar stores user and group names, and restores them correctly. -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] Sanity check: enewuser in binpkg with portage-utils
Hi, keep in mind that when installing a binpkg, src_* functions are skipped, see https://devmanual.gentoo.org/ebuild-writing/functions/ So when you are doing anything with the actual user, you have to do that in a pkg_* function. In case of "exeopts", if you do something like exeopts -m 6710 -g plgudev in any src_* function, the created image will use the GID/UIDs from the system used to create the binpkg. This is probably your problem... Make sure to adjust permissions in pkg_* functions! -- Regards, Thomas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Sanity check: enewuser in binpkg with portage-utils
Hi, I have some ebuilds which use enewuser to create groups and users in pkg_setup(), and make use of those groups and users in src_install() in exeopts, insopts etc. Is there any reason that this would not always work reliably with binpkgs? Ie. regardless of whether I am using portage or portage-utils to install binpkgs with such pkg_setup() and src_install() combinations? Should it matter if the groups and users already exist? I expect no. I would expect it to always work reliably, because exeopts/insopts user and group arguments are looked up by install at run time. I think I had a problem with this yesterday, but I can't reproduce it. Thanks //Peter
Re: [gentoo-dev] can't gpg sign with repoman, but can with git
On 07/20/2017 10:16 AM, Kristian Fiskerstrand wrote: > What I have noticed with regards to git though, but not had time to > debug is that it seems to do something odd with regards to communicating > with the agent to begin with, and possibly spawns an own agent, at least > sufficiently confusing that for smartcard use it fail to access the card > due to locking and needing to re-insert the card.. with similar > mechanism to use it outside of git context again afterwards. And looking into this, the issue is actually a lack of sanitation of the --homedir parameter for gpg-agent, so "$HOME/.gnupg" and "$HOME/.gnupg/" is treated as separate directories and as such two separate agents are started... reported upstream... will be nice to get rid of _that_ annoyance. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
Due to disbanding of Desktop-effects project[1], these packages are up for grabs: dev-python/compizconfig-python x11-apps/fusion-icon x11-libs/compiz-bcop x11-libs/compizconfig-backend-gconf x11-libs/compizconfig-backend-kconfig4 x11-libs/libcompizconfig x11-misc/3dfb x11-misc/3dfm x11-misc/ccsm x11-misc/simple-ccsm x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-themes/emerald-themes x11-wm/compiz x11-wm/compiz-fusion x11-wm/emerald [1] - https://bugs.gentoo.org/show_bug.cgi?id=625712 -- Best regards, Sergey Popov Gentoo developer Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] can't gpg sign with repoman, but can with git
On 07/19/2017 09:24 PM, Paweł Hajdan, Jr. wrote: > * 4 files being committed... > error: gpg failed to sign the data > fatal: failed to write commit object > !!! Exiting on git (shell) error code: 128 you can increase gpg-agent logging verbosity in gpg-agent.conf: log-file /home/user/my.log debug-level guru ... don't share the file outright, as it can contain sensitive info at that debug level.. but it should give you a hint as to what is going on if the request hits gpg-agent (and if not that is a point of info in itself) fwiw, debugging this in #gentoo-crypto might be easier :) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] can't gpg sign with repoman, but can with git
On 07/20/2017 07:49 AM, Andrew Savchenko wrote: > Some pinentry issues imho if GPG_TTY makes it work, at least it was > when I hit that half a year ago with this suggested as a solution. It's > not a solution, it's a workaround, as users need to do something. This is a documented feature from upstream, mainly on secure systems you want pinentry to be directed to a specific terminal and not whichever an application calling gpg is called from, as this can also result in information leak if a fake pinentry is used etc. So by default, pinentry is started with the tty that gpg-agent is started in, which can be a protected environment (even more so with the possibility of remote gpg-agent, allowing it to run in a protected sandbox and communicating solely over IPC) With the graphical pinentries this is a bit different (they are less secure by design, since they are running on a system with a GUI to begin with..) , gnome3 one will use some DBUS funkery, whereby gtk+ and qt ones will be easier to debug as they rely mostly on DISPLAY variable to trigger. By default a curses pinentry is used as fallback (but that requires proper GPG_TTY, of which the proper very much can be the initial tty from the agent) What I have noticed with regards to git though, but not had time to debug is that it seems to do something odd with regards to communicating with the agent to begin with, and possibly spawns an own agent, at least sufficiently confusing that for smartcard use it fail to access the card due to locking and needing to re-insert the card.. with similar mechanism to use it outside of git context again afterwards. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
