[opensuse-factory] suse 13.2: uncredited source used in shadowutils: where from?
I was trying to figure out a behavior/feature in shadowutils and whether it came from the package maintainers, or was an OpenSuse addition as wanted to know where the scripts: "useradd.local" and "groupadd.local" came from. I wanted to report one or more problems affecting both scripts and didn't know if it should be reported to the package "owners"[?] or opensuse. I installed the source rpm for "shadowutils-4.1.5" and then thought it might be as fast or faster to look at the sources from the package URL citing http://pkg-shadow.alioth.debian.org/ . On the site, I see the latest tars being 4.1.4, 4.2, and 4.2.1. I see no listing for the tarball used by OpenSUSE, neither 4.1.5.1 nor 4.1.5. I'm wondering where these packages came from (as well as wondering how 4.1.5 was "listed as being from the "alioth" source server when the source server has no such tar. It may be no big deal, but usually when I see a URL where the source tar is supposed to be from, it's usually verifiable as being there and, for the times I've checked, is usually the same tarball. In this case, taking a security-minded stance, I can't check any signature or checksum to verify that the tarball used to create opensuse binaries was from the attributed website. I'm sure there's some good explanation, but isn't this something that shouldn't happen for released software? Where *DID*, 4.1.5 (and 4.1.5.1) come from -- are they opensuse created versions? Should opensuse be creating versions of packages that are easily confused with the version numbers used on the original site? I.e. normally, I see something like 4.1.4_2.37, where the part after the "_" is some suse-specific/internal version. If the package owners didn't created the source for suse's package, who did? While I might have some belief in the security of the package on the package's source site, what is known about the 4.1.5.1 or 4.1.5 packages? Could they have a malware or a rootkit embedded -- since they aren't easily verified for content as they didn't come from the official source for this package... ??? Thanks... -l -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 1. November 2016, 18:26:50 schrieb L. A. Walsh:
I was trying to figure out a behavior/feature in shadowutils and whether it came from the package maintainers, or was an OpenSuse addition as wanted to know where the scripts:
"useradd.local" and "groupadd.local"
came from.
I wanted to report one or more problems affecting both scripts and didn't know if it should be reported to the package "owners"[?] or opensuse.
I installed the source rpm for "shadowutils-4.1.5" and then thought it might be as fast or faster to look at the sources from the package URL citing http://pkg-shadow.alioth.debian.org/ .
On the site, I see the latest tars being 4.1.4, 4.2, and 4.2.1.
I see no listing for the tarball used by OpenSUSE, neither 4.1.5.1 nor 4.1.5.
I did not find a package called shadowutils on OBS, so I doubt it is openSUSE Standard - where did you get it from Best, Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 02, 2016 at 08:22:37AM +0100, Axel Braun wrote:
Am Dienstag, 1. November 2016, 18:26:50 schrieb L. A. Walsh:
I was trying to figure out a behavior/feature in shadowutils and whether it came from the package maintainers, or was an OpenSuse addition as wanted to know where the scripts:
"useradd.local" and "groupadd.local"
came from.
I wanted to report one or more problems affecting both scripts and didn't know if it should be reported to the package "owners"[?] or opensuse.
I installed the source rpm for "shadowutils-4.1.5" and then thought it might be as fast or faster to look at the sources from the package URL citing http://pkg-shadow.alioth.debian.org/ .
On the site, I see the latest tars being 4.1.4, 4.2, and 4.2.1.
I see no listing for the tarball used by OpenSUSE, neither 4.1.5.1 nor 4.1.5.
I did not find a package called shadowutils on OBS, so I doubt it is openSUSE Standard - where did you get it from
The package is called "shadow". The sources were downloaded at one point in time from above site. I am now adding GPG key verification to the package too. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marcus Meissner wrote:
I did not find a package called shadowutils on OBS, so I doubt it is openSUSE Standard - where did you get it from
13.2
The package is called "shadow".
Different package as Aleksa mentioned... ---- I'm still not certain where the useradd.local and useradd.group files came from -- were they added by opensuse? There's a problem with how they defined and presented in that it doesn't say *when* those files will be called -- before the system useradd, or after? Both have a place, but in my case, I wanted to ensure that users and groups met certain criteria before they were added -- otherwise it requires I go in after a package has been installed and making manual changes to UIDs and GIDs which is sorta a pain. I try to keep the 'ID' portion unique for new additions so any the ID for UID and GID can be the same. It simplifies Windows domain GUID mapping as I use my opensuse machine running winbind to provide ID's for my windows boxes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 7. November 2016, 20:02:34 schrieb L.A. Walsh:
Marcus Meissner wrote:
I did not find a package called shadowutils on OBS, so I doubt it is openSUSE Standard - where did you get it from
--- 13.2
The package is called "shadow".
--- Different package as Aleksa mentioned... ----
Hm, on my 13.2 system: $ LANG=C zypper se -s shadowutils Repository 'openSUSE-13.2-Update' is out-of-date. You can run 'zypper refresh' as root to update it. Loading repository data... Reading installed packages... No packages found. So I can confirm that there is no "shadowutils" package in 13.2.
I'm still not certain where the useradd.local and useradd.group files came from -- were they added by opensuse?
rpm -qf /usr/sbin/useradd.local shadow-4.1.5.1-13.1.2.x86_64 I don't have a useradd.group though, nor a groupadd.local. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Mon, Nov 07, 2016 at 08:02:34PM -0800, L.A. Walsh wrote:
Marcus Meissner wrote:
I did not find a package called shadowutils on OBS, so I doubt it is openSUSE Standard - where did you get it from
13.2
The package is called "shadow".
Different package as Aleksa mentioned... ----
I'm still not certain where the useradd.local and useradd.group files came from -- were they added by opensuse?
Yes, these two scripts are added by openSUSE.
There's a problem with how they defined and presented in that it doesn't say *when* those files will be called -- before the system useradd, or after?
Both have a place, but in my case, I wanted to ensure that users and groups met certain criteria before they were added -- otherwise it requires I go in after a package has been installed and making manual changes to UIDs and GIDs which is sorta a pain.
I try to keep the 'ID' portion unique for new additions so any the ID for UID and GID can be the same.
It simplifies Windows domain GUID mapping as I use my opensuse machine running winbind to provide ID's for my windows boxes.
useradd.local runs after the other user creation stuff. userdel in Factory runs two scripts: userdel-pre.local ... before the standard user deletion stuff userdel-post.local ... after the standard user deletion stuff. Older versions might have just 1 userdel.local script. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marcus Meissner wrote:
userdel in Factory runs two scripts:
userdel-pre.local ... before the standard user deletion stuff userdel-post.local ... after the standard user deletion stuff.
Older versions might have just 1 userdel.local script.
Yup. I assume that's true for useradd and groupadd as well? I'll have to recompile the factory package for my platform -- that should work. I have USERGROUPS_ENAB set to "yes" in /etc/login.defs. It says that USERGROUPS_ENAB only works if UID==GID as well as names being the same -- is that 2nd part right? That conflicts with Windows conventions, where user and group names have to be unique. So I usually setup something like "user" + "usergroup" (or usergrp) when I verify that /etc/{passwd,group} correspond and try to fix created files. Currently (13.2) having it set to YES doesn't seem to force UID's == GID's unless I'm missing something. Thus I wanted to enforce that part of it in the user & group add scripts (i.e. a useradd would create a group of same ID and related-name). At least I know its moving toward a fix... though that same-name requirement need to be fixed to allow serving uniq ID->name mappings to windows (for samba). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
It may be no big deal, but usually when I see a URL where the source tar is supposed to be from, it's usually verifiable as being there and, for the times I've checked, is usually the same tarball.
This is something I've had quite a few concerns about for a while -- there doesn't appear to be a clear policy in place for openSUSE about how we should reference the source of a package. In most cases it looks like a lot of maintainers have a "meh" attitude about it (which isn't great IMO). Personally, when I create packages I use a disabled _service file that contains a link to the git repo (then I use `osc service disabledrun` and commit the .tar.xz generated). If you look in Virtualization:containers all of the packages are structured that way. So maybe we should get some more concrete packaging guidelines on this point?
Where *DID*, 4.1.5 (and 4.1.5.1) come from -- are they opensuse created versions? Should opensuse be creating versions of packages that are easily confused with the version numbers used on the original site? I.e. normally, I see something like 4.1.4_2.37, where the part after the "_" is some suse-specific/internal version.
To answer your actual question (since I had to figure out the exact same thing about the shadowutils package a few months ago). There are actually *two* versions of this project, the Debian one you linked (which is a fork) and the "original" one[1]. AFAIK we ship the "original" one. This github repo[2] has tags for both the debian and upstream versions. If you look at this page[3] on the debian website it links to upstream[1]. [1]: https://github.com/shadow-maint/shadow [2]: https://github.com/Distrotech/shadow-utils [3]: https://pkg-shadow.alioth.debian.org/download.php -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 02, 2016 at 07:50:41PM +1100, Aleksa Sarai wrote:
It may be no big deal, but usually when I see a URL where the source tar is supposed to be from, it's usually verifiable as being there and, for the times I've checked, is usually the same tarball.
This is something I've had quite a few concerns about for a while -- there doesn't appear to be a clear policy in place for openSUSE about how we should reference the source of a package. In most cases it looks like a lot of maintainers have a "meh" attitude about it (which isn't great IMO).
Personally, when I create packages I use a disabled _service file that contains a link to the git repo (then I use `osc service disabledrun` and commit the .tar.xz generated). If you look in Virtualization:containers all of the packages are structured that way.
So maybe we should get some more concrete packaging guidelines on this point?
The package should be referenced by SOURCE URL in the .spec file. This can also be used with "osc service lr download_files", no need for a service file. If possible, specify the GPG signature and keyring. Documented on the WIKI: https://en.opensuse.org/openSUSE:Package_source_verification https://en.opensuse.org/SourceUrls Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, 2 November 2016 10:00 Marcus Meissner wrote:
On Wed, Nov 02, 2016 at 07:50:41PM +1100, Aleksa Sarai wrote:
So maybe we should get some more concrete packaging guidelines on this point?
The package should be referenced by SOURCE URL in the .spec file.
Is there a way to do it if last part of the URL doesn't match tarball name? E.g. if upstream tarball URL is https://github.com/LubosD/twinkle/archive/v1.10.1.tar.gz but the tarball itself is named twinkle-1.10.1.tar.gz ? Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 03 2016, Michal Kubecek
Is there a way to do it if last part of the URL doesn't match tarball name? E.g. if upstream tarball URL is
https://github.com/LubosD/twinkle/archive/v1.10.1.tar.gz
but the tarball itself is named twinkle-1.10.1.tar.gz ?
Source: https://github.com/LubosD/twinkle/archive/v1.10.1.tar.gz#/twinkle-1.10.1.tar... Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
even better way of accomplishing same is to just use / and name file
as you like (keeping /v1.10.1/ part as is as it is required)
https://github.com/LubosD/twinkle/archive/v1.10.1/twinkle-1.10.1.tar.gz
On Thu, Nov 3, 2016 at 9:12 AM, Andreas Schwab
On Nov 03 2016, Michal Kubecek
wrote: Is there a way to do it if last part of the URL doesn't match tarball name? E.g. if upstream tarball URL is
https://github.com/LubosD/twinkle/archive/v1.10.1.tar.gz
but the tarball itself is named twinkle-1.10.1.tar.gz ?
Source: https://github.com/LubosD/twinkle/archive/v1.10.1.tar.gz#/twinkle-1.10.1.tar...
Andreas.
-- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 07 2016, Boris Manojlovic
even better way of accomplishing same is to just use / and name file as you like (keeping /v1.10.1/ part as is as it is required)
https://github.com/LubosD/twinkle/archive/v1.10.1/twinkle-1.10.1.tar.gz
This only works for github, but my solution works for any download server. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Aleksa Sarai
-
Andreas Schwab
-
Axel Braun
-
Boris Manojlovic
-
L. A. Walsh
-
L.A. Walsh
-
Marcus Meissner
-
Michal Kubecek
-
Wolfgang Bauer