Re: [pacman-dev] pacman sorting incompatible with 'sort' command
Maybe pacman should sort according to the current locale, it's all in glibc so it should be trivial to implement. Is there a technical reason for using the C locale or is it just a default? On Fri, May 5, 2017, 9:58 AM brainpower <brainpo...@mailbox.org> wrote: > > Andrew Gregory <andrew.gregor...@gmail.com> wrote: > > > > > > On 05/05/17 at 09:19am, Adesh Kumar wrote: > > > pacman internal sorting on package names differ from the one > implemented in linux 'sort' command. > > > > > > pacman treats '-' (hyphen) differently. > > > > > > > > > Testcase: > > > > > > 1. Install i3 group. It will install i3-wm, i3lock and i3status > > > > > > 2. Check the following commands: > > > > > > --($:~)-- pacman -Qeq | grep i3 > > > i3-wm > > > i3lock > > > i3status > > > > > > > > > --($:~)-- pacman -Qeq | grep i3 | sort > > > i3lock > > > i3status > > > i3-wm > > > > > > --($:~)-- pacman -Qeq | grep i3 | sort -c > > > sort: -:2: disorder: i3lock > > > > pacman sorts according to the C locale. Why does this matter though? > > I don't believe we make any promises about query output order at all, > > let alone that it will match `sort`. > > > > apg > > Hi. > > Well there are no promises I'm aware of, as Andrew said, > but if pacman sorts according to C locale, then you just have to tell > `sort` to use that, too. > It makes sense that the output is different with different locales after > all > and if the same locale is used, chances of matching output are higher. > > The only thing one could complain about is, that it isn't mentioned in the > documentation > that pacman always sorts according to C locale regardless of the systems > locale... > But I don't mind... > > PoC: > > $ pacman -Slq | grep '^i3' > i3-wm > i3blocks > i3lock > i3status > $ pacman -Slq | grep '^i3' | LC_COLLATE=C sort > i3-wm > i3blocks > i3lock > i3status > > > -- > regards, > brainpower > -- Signed, Kieran Colford
Re: [pacman-dev] [PATCH 3/4] util/pkgbuild: fix broken indentation
Is this a whitespace only patch or am I missing something?
On Sat, Feb 25, 2017, 12:21 PM Andrew Gregory, <andrew.gregor...@gmail.com>
wrote:
> ---
> scripts/libmakepkg/util/pkgbuild.sh.in | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/scripts/libmakepkg/util/pkgbuild.sh.in
> b/scripts/libmakepkg/util/pkgbuild.sh.in
> index 7074c8c5..ae8ba5e7 100644
> --- a/scripts/libmakepkg/util/pkgbuild.sh.in
> +++ b/scripts/libmakepkg/util/pkgbuild.sh.in
> @@ -207,14 +207,14 @@ get_integlist() {
> continue
> fi
>
> - # check for e.g. "sha256sums_x86_64"
> - for a in "${arch[@]}"; do
> - local sumname="${integ}sums_${a}[@]"
> - if [[ -n ${!sumname} ]]; then
> - integlist+=("$integ")
> - break
> - fi
> - done
> + # check for e.g. "sha256sums_x86_64"
> + for a in "${arch[@]}"; do
> + local sumname="${integ}sums_${a}[@]"
> + if [[ -n ${!sumname} ]]; then
> + integlist+=("$integ")
> + break
> + fi
> + done
> done
>
> if (( ${#integlist[@]} > 0 )); then
> --
> 2.11.1
>
--
Signed, Kieran Colford
Re: [pacman-dev] [PATCH 0/2] Deprecate md5sums, show sha256sums as an example-by-default.
On Fri, Feb 24, 2017, 8:52 AM Bruno Pagani, <bruno.n.pag...@gmail.com> wrote: Le 24/02/2017 à 04:37, Eli Schwartz a écrit : > On 02/23/2017 10:16 PM, Mike Swanson wrote: >> This is an interesting discussion, I don't exactly mind the points for >> remaining with md5sums as the example, but I do have some issue with it: >> >> I believe the documentation and sample PKGBUILDs should show best >> practices, rather than purposely use a poor practice with the hope that >> a PKGBUILD author fixes it themself. _I_ know to replace the checksum >> function with something better, to use GPG keys where possible, but a >> brand new author would not, and a long-time author may not even realize >> the best practices do not match what they are used to: the example >> PKGBUILDs aren't being changed to show the contrary. >> >> On false senses of security: Yes, there is some blind faith that an AUR >> maintainer just so happened to provide the correct checksums, but >> there's even a faith that the correct GPG keys are used and correct >> source host. Thankfully, it is usually plainly obvious if the latter is >> the case. :-) >> >> On upstream always providing GPG signature files against tarballs: >> Beyond the fact that not all upstreams even do this (and you can make a >> fair argument that the AUR maintainer has no firm reason to believe >> _their_ download was the correct one), I'm not actually entirely >> convinced that they should always be expected to do as such. >> >> This is a difficult position to defend, and it may come down to >> laziness, but hosting sites such as GitHub and GitLab provide automated >> tarball generation (by just using `git archive` on the backend -- it's >> easy to independently verify the archives). Speaking from my >> experience, it has become natural for me to stick with GPG-signing the >> tag in Git itself and ignoring output files such as these. It largely >> comes to “If you need to verify the integrity of the source code, I >> expect you to clone the repository and check that tag, and use `git >> archive | $HASH` to verify the archive GitHub/GitLab provide.” > I encourage you to run `git archive` on your local master repo, and > generate a GPG signature against that... it will be reproducible in the > autogenerated version. Then upload the GPG signature as a release artifact. > > Because you're right, it is sheer laziness. Downloading a potentially > *huge* git repo just to verify signatures, is madness. Try applying that > logic to the linux kernel... *cloning* it begins to approach the length > of time required to *build* it. > Knowing beforehand, how many commits to specify with --depth, is not a > reasonable answer. :) Debian wrote a nice page about this: https://wiki.debian.org/Creating%20signed%20GitHub%20releases Especially the alternative local workflow at the end, that is mostly what Eli proposes above. ;) One example of package doing this is https://github.com/vector-im/riot-web, they included this easily in their release process at https://github.com/matrix-org/matrix-js-sdk/pull/351. If you’re already signing tags used for releases, signing the tarball should really be easy and as underlined by Eli, quite a good idea. So, yes, PGP everywhere please. Cheers, Bruno I agree that PGP everywhere is absolutely something to push for. On the other hand, not every developer is in the web of trust strong set and if you're downloading the package sources from Github then that's probably where you got the PGP key id from as well. An attacker who can highjack your TLS secured source download when you bump the package version could also have fed you a forged PGP key id when you first made the package. Upgrading to stronger checksums is only marginally less secure than using PGP. I think we ought to settle on what to do about these checksums. MD5 and SHA-1 are not strong enough to provide security but they're also too bloated for mere error correction. A change is definitely needed and we should decide on which direction to take. -- Signed, Kieran Colford
Re: [pacman-dev] [PATCH 0/2] Deprecate md5sums, show sha256sums as an example-by-default.
On Thu, 23 Feb 2017 at 16:31 Mike Swanson <mikeonthecompu...@gmail.com> wrote: > Both the MD5 and SHA-1 hash functions have known collision attacks, > providing an attack vector for malicious hosts and MITMs to provide > tampered code without being detected by md5, or sha1, hashing. > > We should move to sha256-by-default, and encourage their use by > changing the documentation and example files to follow suit. The > SHA-2 family of hashes are currently secure against normal attacks > (even at the scale of having Facebook's or Google's datacenters). Int > the future, pacman should gain SHA-3 support though, because SHA-2 > itself has some theoretical preimage attacks and possible collision > attacks. <https://crypto.stackexchange.com/questions/26336/sha512-faster-than-sha256> points out that using sha512 is faster than sha256 so I'd rather not waste my time calculating hashes without a good reason > > Mike Swanson (2): > proto: Encourage the use of sha256sums by example. > doc, makepkg.conf: Deprecate md5sums, show examples using sha256sums. > > doc/PKGBUILD-example.txt | 4 ++-- > doc/PKGBUILD.5.txt | 31 +++ > doc/makepkg-template.1.txt | 2 +- > etc/makepkg.conf.in| 2 +- > proto/PKGBUILD-split.proto | 2 +- > proto/PKGBUILD-vcs.proto | 2 +- > proto/PKGBUILD.proto | 2 +- > 7 files changed, 26 insertions(+), 19 deletions(-) > > -- > 2.11.1 > -- Signed, Kieran Colford
Re: [pacman-dev] [PATCH] Provide a better guess about who the packager is.
After taking in your input, I'd like you to consider this revised patch. I've cleaned up the scraping and set it up to fallback to old behaviour if it can't find an intelligent and resonable default.
[pacman-dev] [PATCH v2] Provide a better guess about who the packager is.
The system usually has enough information in various places to guess
the name and email of the person running the makepkg script. We can
use this to make the defaults more intelligent. This particular
implemenation should provide relatively good guess that's compatible
with other programs (i.e. git).
Signed-off-by: Kieran Colford <kie...@kcolford.com>
---
scripts/makepkg.sh.in | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 29408929..b2a0b89a 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -613,12 +613,22 @@ write_kv_pair() {
done
}
+default_packager() {
+ local user="${USER:-$(whoami)}"
+ # Try to find the user's real name is in the environment or
+ # the passwd databse.
+ local name="${NAME:-$(getent passwd "${user}" | cut -d : -f 5 | cut -d
, -f 1)}"
+ # Try to find the user's email in the environment only.
+ local email="${EMAIL}"
+ echo "${name:-Unknown Packager}${email:+ <${email}>}"
+}
+
write_pkginfo() {
local builddate=$(date -u "+%s")
if [[ -n $PACKAGER ]]; then
local packager="$PACKAGER"
else
- local packager="Unknown Packager"
+ local packager="$(default_packager)"
fi
local size="$(@DUPATH@ @DUFLAGS@)"
--
2.11.0
Re: [pacman-dev] [PATCH] Provide a better guess about who the packager is.
Really? That is a problem then. Could we improve that feature to check that the PACKAGER variable matches a userid of the key that signs said package? That would not only be a stronger requirement (forcing a correct makepkg.conf, rather than one that's just set so you're running around trying to find "hfkskxfjks"), but it would also remove the reliance on makepkg's implementation defined behavior. I could try submitting a patch to the relevant mailing list of you think it's worthwhile. On Wed, Feb 1, 2017, 9:19 AM Dave Reisner, <d...@falconindy.com> wrote: On Wed, Feb 01, 2017 at 01:48:09PM +, Kieran Colford wrote: > Exactly, if they have PACKAGER set then we don't make any guesses at all, > they've already told us exactly what they want. But this patch gets rid of a lovely feature in arch's db-scripts which causes an unset PACKAGER variable (resulting in "Unknown Packager") to reject packages from being pushed into the repos. Your patch breaks that, and we end up having to hunt down whomever "noclaf@rampage" is to make them fix their ~/.makepkg.conf. > On Wed, Feb 1, 2017, 8:43 AM Dave Reisner, <d...@falconindy.com> wrote: > > > On Feb 1, 2017 08:33, "Kieran Colford" <kie...@kcolford.com> wrote: > > > > Would you care to share with us what pile of shit it returns? I can't fix > > something when I don't know what's wrong. > > > > I never suggested that we work around laziness, people should absolutely > > configure their system properly (I personally think violators should be > > punished with regular kernel panics, but I don't think Linus will accept my > > patch). > > > > I'm just trying to give default values that conform to what a user expects > > to see: if they added a real name on account creation then it should show > > up wherever a real name is needed, if they set the EMAIL environment > > variable then software should assume that's the user's email and use it. > > Those are both recommended by the wiki too. > > > > > > And if they set PACKAGER it leaks into makepkg just the same, but better? > > > > > > > > On Wed, Feb 1, 2017, 12:47 AM Allan McRae, <al...@archlinux.org> wrote: > > > > > On 01/02/17 08:10, Kieran Colford wrote: > > > > The system usually has enough information in various places to guess > > > > the name and email of the person running the makepkg script. Use these > > > > instead of defaulting to "Unknown Packager" to minimize configuration > > > > necessary by the user. This particular implemenation should provide > > > > relatively good guess that's compatible with other programs > > > > (i.e. git). > > > > > > > > Signed-off-by: Kieran Colford <kie...@kcolford.com> > > > > > > This returns a pile of shit on my system We are not going to work > > > around laziness. > > > > > > A > > > > > -- > > > > Signed, Kieran Colford > > > -- > > Signed, Kieran Colford -- Signed, Kieran Colford
Re: [pacman-dev] [PATCH] Provide a better guess about who the packager is.
Exactly, if they have PACKAGER set then we don't make any guesses at all, they've already told us exactly what they want. On Wed, Feb 1, 2017, 8:43 AM Dave Reisner, <d...@falconindy.com> wrote: > On Feb 1, 2017 08:33, "Kieran Colford" <kie...@kcolford.com> wrote: > > Would you care to share with us what pile of shit it returns? I can't fix > something when I don't know what's wrong. > > I never suggested that we work around laziness, people should absolutely > configure their system properly (I personally think violators should be > punished with regular kernel panics, but I don't think Linus will accept my > patch). > > I'm just trying to give default values that conform to what a user expects > to see: if they added a real name on account creation then it should show > up wherever a real name is needed, if they set the EMAIL environment > variable then software should assume that's the user's email and use it. > Those are both recommended by the wiki too. > > > And if they set PACKAGER it leaks into makepkg just the same, but better? > > > > On Wed, Feb 1, 2017, 12:47 AM Allan McRae, <al...@archlinux.org> wrote: > > > On 01/02/17 08:10, Kieran Colford wrote: > > > The system usually has enough information in various places to guess > > > the name and email of the person running the makepkg script. Use these > > > instead of defaulting to "Unknown Packager" to minimize configuration > > > necessary by the user. This particular implemenation should provide > > > relatively good guess that's compatible with other programs > > > (i.e. git). > > > > > > Signed-off-by: Kieran Colford <kie...@kcolford.com> > > > > This returns a pile of shit on my system We are not going to work > > around laziness. > > > > A > > > -- > > Signed, Kieran Colford > -- Signed, Kieran Colford
Re: [pacman-dev] [PATCH] Provide a better guess about who the packager is.
Would you care to share with us what pile of shit it returns? I can't fix something when I don't know what's wrong. I never suggested that we work around laziness, people should absolutely configure their system properly (I personally think violators should be punished with regular kernel panics, but I don't think Linus will accept my patch). I'm just trying to give default values that conform to what a user expects to see: if they added a real name on account creation then it should show up wherever a real name is needed, if they set the EMAIL environment variable then software should assume that's the user's email and use it. Those are both recommended by the wiki too. On Wed, Feb 1, 2017, 12:47 AM Allan McRae, <al...@archlinux.org> wrote: > On 01/02/17 08:10, Kieran Colford wrote: > > The system usually has enough information in various places to guess > > the name and email of the person running the makepkg script. Use these > > instead of defaulting to "Unknown Packager" to minimize configuration > > necessary by the user. This particular implemenation should provide > > relatively good guess that's compatible with other programs > > (i.e. git). > > > > Signed-off-by: Kieran Colford <kie...@kcolford.com> > > This returns a pile of shit on my system We are not going to work > around laziness. > > A > -- Signed, Kieran Colford
Re: [pacman-dev] [PATCH] Provide a better guess about who the packager is.
I would have added better defaults for when getent returns nothing for us
to use, but my bash skills aren't up to par for that. I would love to get a
better fallback for that. Currently it will just give a blank if you didn't
set your full name in /etc/passwd
I also didn't realize the hostname command wasn't included in base-devel.
It didn't even occur to me to not have it. I can further fallback on uname
-n like you suggested or even echo localhost
A system configured according to the wiki will give even more distinctive
and useful information with hostname --fqdn than it will with just uname
-n, so I would keep it as the default and fallback to uname if it doesn't
work. The
On Tue, Jan 31, 2017, 7:47 PM Eli Schwartz, <eschwart...@gmail.com> wrote:
> On 01/31/2017 05:10 PM, Kieran Colford wrote:
> > The system usually has enough information in various places to guess
> > the name and email of the person running the makepkg script. Use these
> > instead of defaulting to "Unknown Packager" to minimize configuration
> > necessary by the user. This particular implemenation should provide
> > relatively good guess that's compatible with other programs
> > (i.e. git).
> >
> > Signed-off-by: Kieran Colford <kie...@kcolford.com>
> > ---
> > scripts/makepkg.sh.in | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
> > index 29408929..65114862 100644
> > --- a/scripts/makepkg.sh.in
> > +++ b/scripts/makepkg.sh.in
> > @@ -618,7 +618,7 @@ write_pkginfo() {
> > if [[ -n $PACKAGER ]]; then
> > local packager="$PACKAGER"
> > else
> > - local packager="Unknown Packager"
> > + local packager="${NAME:-$(getent passwd ${USER:-$(whoami)}
> | cut -d : -f 5 | cut -d , -f 1)} <${EMAIL:-${USER:-$(whoami)}@$(hostname
> --fqdn)}>"
>
> What happens when someone initially created their user without making
> use of the "useradd --comment" option? I know I didn't bother...
> Do you have a fallback for when that is empty?
>
> More: what about building in a clean chroot? This will invariably
> produce nothing but "bash: hostname: command not found" on stderr. (But
> the "$NAME" would evaluate to "builduser" anyway. I am not entirely sure
> why that field is even filled out with that much in the first place, but
> that is another matter entirely...)
>
> That would be because "hostname" is provided by inetutils, which is not
> installed as part of base-devel.
>
> Warning: Personal opinion follows.
> I personally dislike its useless output of "localhost.localdomain" too,
> even when git uses that. (I would much prefer using the local machine
> name at least, available through e.g. uname -n which is at least
> guaranteed available as part of coreutils, besides being 100% more
> distinctive for the average home system.)
>
> > fi
> >
> > local size="$(@DUPATH@ @DUFLAGS@)"
> >
>
> Trying to scrape information from the OS in order to get better defaults
> is not a terrible idea, but getting rid of any fallback whatsoever in
> the process doesn't strike me as useful.
>
> I also think everyone, without exception, should be configuring their
> makepkg.conf to provide an *actual* email, rather than falling back to
> the machine name. For the same reason that git users should do so (and
> git redeems itself by verbosely warning you every time you rely on that
> autodetected value). Unless of course they simply don't care about that
> field, in which case we can probably use "flbkoaasdfklpopefevq" instead
> of "Unknown Packager", and they'd never notice the difference.
> Though as I have no actual power here, I probably cannot get *that*
> enforced. :(
>
> --
> Eli Schwartz
>
> --
Signed, Kieran Colford
