Re: 2443 packages indirectly depend on unsupported openssl@1.0.2u

[Leo Famulari]

On Thu, Mar 11, 2021 at 05:46:47AM +0100, Léo Le Bouter wrote:
> Hello!
> 
> $ ./pre-inst-env guix refresh -l openssl@1.0.2u
> Building the following 2320 packages would ensure 2443 dependent
> [...]
> 
> As upstream says at  >:
> > Version 1.0.2 is no longer supported. Extended support for 1.0.2 to
> gain access to security fixes for that version is available.
> 
> What can we do about this you think?

We have started discussing it here:

https://bugs.gnu.org/46602

Re: Commit pushed to master with unauthorised signature

[Maxime Devos]

On Thu, 2021-03-11 at 00:15 +0100, Taylan Kammer wrote:
> [...]
> Damn, sorry about that.  I assumed of course that an improperly signed
> commit would not be accepted, so I didn't pay any special mind.
> 
> However, I also assumed that adding a new GPG key to my savannah.gnu.org
> account would be sufficient.

"guix pull" only looks at the git repo (the .guix-authorizations file + the
keyring branch), and not anything else provided by savannah.  Doing so would
introduce an additional point where the "guix pull" mechanism could be
compromised.  The git repository could as well have been hosted at
$RANDOM_SPY_AGENCY or $RANDOM_FORGE.

(See ‘16.8 Commit Access’, ‘6.8 Specifying Channel Authorizations’ and
‘7.4 Invoking ‘guix git authenticate’’).

> Are the GPG keys added to one's Savannah account unrelated to commit
> signing in the Guix repo,

Yes (though they probably are same in practice).

> or are they not automatically synced,

Yes, they aren't.

> this a further bug?..

No, savannah is not ‘trusted’ beyond being online, as that would introduce
another point where "guix pull" could be compromised.

Maxime.


signature.asc
Description: This is a digitally signed message part

guix home

[Andrew Tropin]

Hi guix!

There is an implementation of `guix home` subcommand, which behaves
similar to `guix system`, allowing declaratively manage applications and
their configurations, but for a particular user, not the whole OS:
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu

* Overview
It possible to define the desired environment with home-environment
record, which contains a list of home-services and few other
configuration options and build and install it with `guix home
reconfigure`. The service extension mechanism works the same way as in
operating-system and utilize fold-services from (gnu services).

Current set of implemented essential services:
- home-service :: return the derivation
- home-profile :: manages a separate profile with packages provided by
user or other services
- home-environment-vars :: allows to set env vars for user's shell
- home-shepherd :: manages user's shepherd, can be extended by other services
- home-run-on-first-login :: launches shepherd and some other one-time actions
- home-run-on-reconfigure :: update shepherd configuration and update
symlinks from ~/ and ~/.config to guix-home-environment/files
- home-symlink-manager :: extends on-reconfigure with a update-symlinks script

For now I personally manage just a few applications on my system and it
seems that everything works as expected, but I plan to migrate all the
"dotfiles" to it in nearest future. AFAIK, some people succesfully use
it on other GNU/Linux distributions.

* Alternative solutions
In contrast to guix-home-manager, `guix home` doesn't introduce any too
innovative approaches (those ideas are cool, but in some use cases are
too radical), `guix home` uses the same extension mechanism [fn:1] as
guix system services and doesn't require to make HOME read-only. Thus,
it's possible to start using `guix home` gradually, along with other
tools and workflows (stow, guix package, chezmoi, yadm, etc).

Talking about Nix's home-manager: it's a nice software, but maintained
separately from nix package manager and kinda disconnected from Nix
itself, which introduce a lot of duplications between NixOS modules and
home-manager modules, requires additional installation steps and overall
makes it harder to use for not very experienced nix users. Probably, we
can learn from it and do better here.

* Future steps
`guix home` still under active development, but already complete enough
for exloration and early adoption. There is no any documentation yet,
because things were changing often and probably will change one more
time during comming cleanup, however there were few video streams,
explaining internals of `guix home`:
mpv https://youtu.be/t3zRzQnarUI
mpv https://youtu.be/4lJaVzxO_Bs
mpv https://youtu.be/ZRQtCvo8MoM

In addition to documentation it will be necessary to implement a lot of
home-services for different tools, add rollback, shepherd-graph,
extension-graph and other actions, but before doing it I would like to
spend some time polishing essential services and decide on upstreaming
the tool to guix itself.

The question is: do we want and need at all `guix home` to be a part of
the guix? As for me, the tool seems like a natural addition to guix's
declarative configuration management approach and covers the missing
piece of user space software management and as I mentioned early
upstreaming will allow to make it better integrated with the rest of the
guix and easier to use for newcommers and casual users, but my
perception is obviously biased.

Dear maintainers and users, what do you think about making `guix home` a
part of guix?

* Footnotes

[fn:1] https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

--
Best regards,
Andrew Tropin

2443 packages indirectly depend on unsupported openssl@1.0.2u

[Léo Le Bouter]

Hello!

$ ./pre-inst-env guix refresh -l openssl@1.0.2u
Building the following 2320 packages would ensure 2443 dependent
[...]

As upstream says at :
> Version 1.0.2 is no longer supported. Extended support for 1.0.2 to
gain access to security fixes for that version is available.

What can we do about this you think?

Léo


signature.asc
Description: This is a digitally signed message part

GNOME 3.34 in GNU Guix and security

[Léo Le Bouter]

Hello!

I must come to the conclusion that using GNOME 3.34 in GNU Guix right
now is just straight out insecure. I would advise we either, get rid of
GNOME, backport all individual security patches (they can be
numerous..), or upgrade GNOME to latest and keep up over time.

I don't think we can afford to spend time backporting security fixes to
the numerous GNOME packages with CVEs, not with current resources, it
is time-consuming.

Léo


signature.asc
Description: This is a digitally signed message part

pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

[Léo Le Bouter]

CVE-2021-21375  00:15
PJSIP is a free and open source multimedia communication library
written in C language implementing standard based protocols such as
SIP, SDP, RTP, STUN, TURN, and ICE. In PJSIP version 2.10 and earlier,
after an initial INVITE has been sent, when two 183 responses are
received, with the first one causing negotiation failure, a crash will
occur. This results in a denial of service.

CVE-2020-15260  00:15
PJSIP is a free and open source multimedia communication library
written in C language implementing standard based protocols such as
SIP, SDP, RTP, STUN, TURN, and ICE. In version 2.10 and earlier, PJSIP
transport can be reused if they have the same IP address + port +
protocol. However, this is insufficient for secure transport since it
lacks remote hostname authentication. Suppose we have created a TLS
connection to `sip.foo.com`, which has an IP address `100.1.1.1`. If we
want to create a TLS connection to another hostname, say `sip.bar.com`,
which has the same IP address, then it will reuse that existing
connection, even though `100.1.1.1` does not have certificate to
authenticate as `sip.bar.com`. The vulnerability allows for an insecure
interaction without user awareness. It affects users who need access to
connections to different destinations that translate to the same
address, and allows man-in-the-middle attack if attacker can route a
connection to another destination such as in the case of DNS spoofing.

Upstream has not made a release yet, I advise we wait for a release on
their end then upgrade. To be monitored.


signature.asc
Description: This is a digitally signed message part

Re: GNU Guix (pull?) on i686 broke after zstd grafting

[Léo Le Bouter]

On Wed, 2021-03-10 at 11:37 +0100, Ludovic Courtès wrote:
> So I think there’s a genuine bug here.  Could you take a look?  At
> worst, we should skip the offending test on i686 (and perhaps
> ARMv7?).

I pushed 2bcfb944bdd2f476ef8d34802fed436e4fdda0ab which disables tests
entirely in the graft.

At least this fixes the issue, if anyone wants to still enable tests,
feel free, no energy for that myself now.

This will do while we wait for an upstream patch.

Léo


signature.asc
Description: This is a digitally signed message part

GNOME Orca 'orca' package mislabeled by 'guix lint -c cve'

[Léo Le Bouter]

This is GNOME Orca in the CPE database: 
https://nvd.nist.gov/products/cpe/detail/660937?namingFormat=2.3&orderBy=CPEURI&keyword=orca&status=FINAL

Currently CVE-2020-9298 is being wrongly reported by 'guix lint -c cve'
because vendor is not taken into account, therefore:
"cpe:2.3:a:spinnaker:orca" also matches.

Reminder that we need cpe-vendor property as told in <
https://issues.guix.gnu.org/40142>.

I would like to tag the package but currently cannot because cpe-vendor 
does not exist yet.


signature.asc
Description: This is a digitally signed message part

glib@2.62.6 is vulnerable to CVE-2021-27218 and CVE-2021-27219

[Léo Le Bouter]

Upstream does not provide fixes for the 2.62.x series so we need to
backport ourselves.

I would rather switch to upstream-supported version (2.66.x or later)
as backporting patches does not appear sustainable for us, we already
have enough on our plate.

See:
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1942 (CVE-2021-
27218)
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1944 (CVE-2021-
27218)
- https://gitlab.gnome.org/GNOME/glib/-/issues/2319 (CVE-2021-27219)

Léo


signature.asc
Description: This is a digitally signed message part

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Tobias Geerinckx-Rice]

zimoun 写道：

Therefore, is it possible to “restart” the build on Cuirass


I used ‘guix build’, not Cuirass (AIUI its CLI is still ‘poke the 
SQL database with a stick’?).


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Tobias Geerinckx-Rice]

Simon,

zimoun 写道：

Attached, the list of the 180 ghc-* packages.


I've started the builds on berlin except haddock.  Not restarted: 
none of these had failed. Judging by how quickly it finished I 
think most of them had already been built, but I didn't pay enough 
attention to be certain.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Commit pushed to master with unauthorised signature

[Taylan Kammer]

On 10.03.2021 22:22, Tobias Geerinckx-Rice wrote:

> Earlier today the following commit was pushed to master:
> 
> --8<---cut here---start->8---
> commit 15092548804b6c50ea276d098f76a79bd0042398
> gpg: Signature made Wed Mar 10 19:55:39 2021 CET
> gpg:    using RSA key 51A0982A58B64622464833085EEB3986CB2F65ED
> gpg: Good signature from "Taylan Kammer (Debian10VM)
> " [unknown]
> Primary key fingerprint: 51A0 982A 58B6 4622 4648  3308 5EEB 3986 CB2F 65ED
> Author: Taylan Kammer 
> 
>    gnu: guile-bytestructures: Update to 1.0.10.
> 
>    * gnu/packages/guile.scm (guile-bytestructures): Update to    1.0.10.
> --8<---cut here---end--->8---
> 
> The key with fingerprint 51A0 982A 58B6 4622 4648  3308 5EEB 3986 CB2F
> 65ED is not present in .guix-authorizations, nor in the ‘keyring’
> branch.  This broke ‘guix pull’ for all users[0]:
> 
> --8<---cut here---start->8---
> guix pull: error: could not authenticate commit
> 15092548804b6c50ea276d098f76a79bd0042398: key 51A0 982A 58B6 4622 4648
> 3308 5EEB 3986 CB2F 65ED is missing
> --8<---cut here---end--->8---

Damn, sorry about that.  I assumed of course that an improperly signed
commit would not be accepted, so I didn't pay any special mind.

However, I also assumed that adding a new GPG key to my savannah.gnu.org
account would be sufficient.  I did that via the web interface, and
ensured that the encryption test is successful.  The commit is signed
with that new GPG key.

Are the GPG keys added to one's Savannah account unrelated to commit
signing in the Guix repo, or are they not automatically synced, or is
this a further bug?..


- Taylan

Release 1.2.1: Remove 31 Python 2 packages

[zimoun]

Hi,

Using “guix weather --display-missing” at commit 6bed29b, I have
identified these 31 Python 2 packages to remove:

--8<---cut here---start->8---
python2-arrow
python2-cairocffi
python2-cairocffi
python2-dulwich
python2-fido2
python2-flask
python2-flask-babel
python2-flask-htmlmin
python2-flask-login
python2-flask-multistatic
python2-flask-wtf
python2-furl
python2-graphql-core
python2-httpbin
python2-ipykernel
python2-ipyparallel
python2-ipython
python2-ipython-cluster-helper
python2-ipywidgets
python2-jupyter-console
python2-mpd2
python2-mutagen
python2-nbxmpp
python2-pyfakefs
python2-rq
python2-sh
python2-stem
python2-tables
python2-utils
python2-widgetsnbextension
python2-wsgiproxy2
python2-yubikey-manager
--8<---cut here---end--->8---


They do not build.  The Python 3 variant builds or does not exist.

Last, “guix refresh -l ” is fine.


Any objection?


Cheers,
simon

Commit pushed to master with unauthorised signature

[Tobias Geerinckx-Rice]

Guix,

I have very little time to write a proper post-mortem.  Luckily, 
thanks to the prompt help of rwp of #savannah fame and Ludo's sane 
‘guix pull’ design, there's not much to report, although there's 
something to improve.


Despite the scary title, at no point did anything untoward or 
malicious happen.  Users were not at risk.


Earlier today the following commit was pushed to master:

--8<---cut here---start->8---
commit 15092548804b6c50ea276d098f76a79bd0042398
gpg: Signature made Wed Mar 10 19:55:39 2021 CET
gpg:using RSA key 
51A0982A58B64622464833085EEB3986CB2F65ED
gpg: Good signature from "Taylan Kammer (Debian10VM) 
" [unknown]
Primary key fingerprint: 51A0 982A 58B6 4622 4648  3308 5EEB 3986 
CB2F 65ED

Author: Taylan Kammer 

   gnu: guile-bytestructures: Update to 1.0.10.

   * gnu/packages/guile.scm (guile-bytestructures): Update to 
   1.0.10.

--8<---cut here---end--->8---

The key with fingerprint 51A0 982A 58B6 4622 4648  3308 5EEB 3986 
CB2F 65ED is not present in .guix-authorizations, nor in the 
‘keyring’ branch.  This broke ‘guix pull’ for all users[0]:


--8<---cut here---start->8---
guix pull: error: could not authenticate commit 
15092548804b6c50ea276d098f76a79bd0042398: key 51A0 982A 58B6 4622 
4648 3308 5EEB 3986 CB2F 65ED is missing

--8<---cut here---end--->8---

The only solution to that is to remove the offending commit 
upstream.  Our Savannah git repository does not allow deleting or 
force-pushing master for safety reasons.  Helpful Bob Proulx of 
the Savannah team manually reset the remote master branch back to 
the previous[1] commit.


I have pushed Taylan's commit as 
b1eb7448370bbd4d494cf9f3fddae88dd0de2ca3, signed with my own key.


The good news is that ‘guix pull’ commit authentication has passed 
real-world testing, and that the mess was relatively transparent 
to users: ‘guix pull’ continues to work without extra options, 
even for those who pulled between 150925 and b1eb74 and got a 
scary error.


The less-good news is that our remote git hook should never have 
allowed this to happen in the first place, and that this weakness 
has been known for... well, a while[2].  Any committer can DoS 
guix pull in a way that even the maintainers can't fix unaided.


This also highlights the fact that many people[3] are currently 
unconditionally trusted with commit access.  This includes 
‘currently inactive members’: Savannah has no way to disable or 
even restrict commit access (to specific branches, subdirectories, 
or even repositories(?)) without removing membership altogether. 
The chance of mistakes, key confusion, forgotten commit privileges 
grows.


lfam has started removing certain inactive people from this list, 
but removing people is not a fun job nor something one proactive 
volunteer should be tasked with alone.


Kind regards,

T G-R

[0]: https://logs.guix.gnu.org/guix/2021-03-10.log#205043
[1]: 60174c9c8c307be43450af38ce7c4e268278e07c,
[2]: 
https://savannah.nongnu.org/support/?func=detailitem&item_id=109104

[3]: https://savannah.gnu.org/project/memberlist.php?group=guix


signature.asc
Description: PGP signature

Release 1.2.1: Cuirass failed to build Haskell 179 packages

[zimoun]

Hi,

Using the command “guix weather --display-missing” at commit 6bed29b, I
identify 180 packages ghc-* which are missing.  Then I locally rebuild
all of them and they build successfully.  The only one broken is:

  ghc-haddock

Therefore, is it possible to “restart” the build on Cuirass of these 179
ghc-* packages?  It could be nice to have substitutes for the next
release.

And if someone is in the mood to check why ghc-haddock is broken. :-)


Attached, the list of the 180 ghc-* packages.

Thanks,
simon

ghc-abstract-deque
ghc-abstract-par
ghc-active
ghc-aeson-compat
ghc-aeson-qq
ghc-annotated-wl-pprint
ghc-atomic-primops
ghc-atomic-write
ghc-atomic-write
ghc-aws
ghc-base-unicode-symbols
ghc-basic-prelude
ghc-bencode
ghc-bindings-dsl
ghc-bloomfilter
ghc-bytes
ghc-bytestring-handle
ghc-bytestring-lexing
ghc-bzlib-conduit
ghc-cairo
ghc-cborg-json
ghc-cereal-conduit
ghc-cgi
ghc-chart
ghc-chart-cairo
ghc-cmark
ghc-concurrent-extra
ghc-conduit-algorithms
ghc-conduit-zstd
ghc-configurator
ghc-convertible
ghc-cryptohash
ghc-curl
ghc-data-accessor
ghc-data-accessor-transformers
ghc-data-fix
ghc-dav
ghc-dbus
ghc-dense-linear-algebra
ghc-descriptive
ghc-diagrams-core
ghc-diagrams-lib
ghc-diagrams-solve
ghc-diagrams-svg
ghc-disk-free-space
ghc-doclayout
ghc-dotgen
ghc-double-conversion
ghc-emojis
ghc-errorcall-eq-instance
ghc-exactprint
ghc-feed
ghc-filepath-bytestring
ghc-findbin
ghc-generic-random
ghc-generic-random
ghc-genvalidity
ghc-genvalidity-property
ghc-haddock
ghc-haddock-api
ghc-happstack-server
ghc-haskeline
ghc-haskell-src
ghc-haskell-src-meta
ghc-hasktags
ghc-hex
ghc-highlighting-kate
ghc-hmatrix
ghc-hmatrix-gsl
ghc-hmatrix-gsl-stats
ghc-hmatrix-special
ghc-hpack
ghc-http-reverse-proxy
ghc-ifelse
ghc-infer-license
ghc-inline-c
ghc-inline-c-cpp
ghc-inspection-testing
ghc-interpolate
ghc-intervalmap
ghc-intervals
ghc-io-streams-haproxy
ghc-iwlib
ghc-jira-wiki-markup
ghc-js-flot
ghc-js-jquery
ghc-language-glsl
ghc-libffi
ghc-libmpd
ghc-linear
ghc-llvm-hs
ghc-llvm-hs-pure
ghc-magic
ghc-managed
ghc-markdown-unlit
ghc-memotrie
ghc-missingh
ghc-monad-par
ghc-monad-par-extras
ghc-mountpoints
ghc-multipart
ghc-network-multicast
ghc-non-negative
ghc-nonce
ghc-numeric-extras
ghc-operational
ghc-optional-args
ghc-options
ghc-pandoc
ghc-pandoc-citeproc
ghc-parsec-numbers
ghc-path
ghc-path-io
ghc-pgp-wordlist
ghc-pqueue
ghc-pretty-simple
ghc-prettyclass
ghc-prettyprinter
ghc-prettyprinter
ghc-prettyprinter-ansi-terminal
ghc-process-extras
ghc-project-template
ghc-psqueue
ghc-pwstore-fast
ghc-regex
ghc-regex-applicative
ghc-regex-compat
ghc-regex-compat-tdfa
ghc-regex-pcre
ghc-repline
ghc-repline
ghc-safe-exceptions
ghc-safeio
ghc-safesemaphore
ghc-say
ghc-scalpel
ghc-sendfile
ghc-snap-core
ghc-snap-server
ghc-special-values
ghc-splitmix
ghc-spoon
ghc-statistics
ghc-stm-conduit
ghc-storable-complex
ghc-storable-record
ghc-storable-tuple
ghc-storablevector
ghc-svg-builder
ghc-tar
ghc-tar-conduit
ghc-tasty-rerun
ghc-text-binary
ghc-text-conversions
ghc-text-manipulate
ghc-text-metrics
ghc-th-expand-syns
ghc-th-orphans
ghc-th-reify-many
ghc-threads
ghc-timeit
ghc-timezone-olson
ghc-timezone-series
ghc-tldr
ghc-torrent
ghc-turtle
ghc-unagi-chan
ghc-union-find
ghc-unsafe
ghc-uri-bytestring
ghc-validation
ghc-validity
ghc-vector-binary-instances
ghc-wai-cors
ghc-wcwidth
ghc-weigh
ghc-wl-pprint
ghc-xml-hamlet
ghc-xmonad-contrib
ghc-zstd

Re: bsdiff package vulnerable to CVE-2020-14315

[Léo Le Bouter]

On Wed, 2021-03-10 at 12:32 -0500, Leo Famulari wrote:
> Well, we could also just remove this package. It sounds like it is
> not
> supported on Linux. Does it offer some unique functionality?

I would advocate for removal of the package, or at least warning about
absence of security patches for security issues at install/show time.


signature.asc
Description: This is a digitally signed message part

Release 1.2.1: remove clang@3.6?

[zimoun]

Hi,

The package clang-runtime@3.6.2 is broken (commit 6bed29b) and giving a
look to:



it seems broken since long time.  I propose to remove:

 clang
 clang-runtime
 clang-toolchain

@3.6.2.  Any objection?


Note that llvm@3.6.2 cannot be removed because of the package clamav.

Cheers,
simon

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

Hi Leo,

On Wed, 10 Mar 2021 at 13:06, Leo Famulari  wrote:
> On Wed, Mar 10, 2021 at 06:49:37PM +0100, zimoun wrote:

>> I could miss something but I was not suggesting to cherry-pick. :-)
>> Cherry-picking means use the current packaged version and backport to it
>> the commit(s) fixing the issue.
>
> I know you were not suggesting to cherry-pick. But that is what this
> thread is about: the best workflow for cherry-picking patches.

Ah sorry, I have not read the initial message:

While patching packages for security issues, I often am needing
to get some patches from git repos because upstream does not
make releases.

as it was about cherry-picking but how to have security fixes included…

>> I am suggesting to update the packaged version to the upstream version
>> at commit.  But maybe it is not possible because the new upstream has
>> changed some API or whatever breaking some dependants.
>
> We can do that, and sometimes we do. I think we should avoid it when
> possible, since it's rare that upstream projects intend for us to
> distribute their development branches.

…and all is clear. :-)


Sorry for the noise so.

Cheers,
simon

Re: Release on April 18th?

[Efraim Flashner]

On March 10, 2021 3:59:07 PM UTC, zimoun  wrote:
>Hi Efraim,
>
>On Wed, 10 Mar 2021 at 17:30, Efraim Flashner 
>wrote:
> 
>>> Does it make sense to merge wip-ppc64le and core-updates?
>>> 
>> I wanted an Easy Win™ and I've pushed a branch
>wip-ppc64le-for-master,
>> which cherry-picked (I think) all of the powerpc64le commits and
>> adjusted them to work against master WITHOUT affecting other
>> architectures.
>>
>> I don't know why I thought it was an easy win, but if it looks good
>to
>> everyone I don't see why we couldn't merge powerpc64le into master by
>> the end of the week.
>
>So you confirm that cherry-picking from core-updates (as I suggested
>here [1]) is a bad idea, i.e., not an Easy Win™.  Anyway.
>
>IIUC, the remaining part is the GCC upgrade, right?
>
>
>1: <

My understanding was that the gcc upgrade was necessary for powerpc64le with 
the next version of glibc. I think what we need now is people with powerpc64le 
hardware to test the branch.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

Hi Leo,

On Wed, 10 Mar 2021 at 12:09, Leo Famulari  wrote:
> On Wed, Mar 10, 2021 at 02:42:32PM +0100, zimoun wrote:
>> If the package already uses git-fetch, why not directly uses the commit
>> fixing the issue as source?
>
> It's different to build from a Git commit vs to cherry-pick a single
> commit.

I could miss something but I was not suggesting to cherry-pick. :-)
Cherry-picking means use the current packaged version and backport to it
the commit(s) fixing the issue.

I am suggesting to update the packaged version to the upstream version
at commit.  But maybe it is not possible because the new upstream has
changed some API or whatever breaking some dependants.


Cheers,
simon

Re: Generate diff with git-diff and use in patches field of packages

[Leo Famulari]

On Wed, Mar 10, 2021 at 06:49:37PM +0100, zimoun wrote:
> I could miss something but I was not suggesting to cherry-pick. :-)
> Cherry-picking means use the current packaged version and backport to it
> the commit(s) fixing the issue.

I know you were not suggesting to cherry-pick. But that is what this
thread is about: the best workflow for cherry-picking patches.

> I am suggesting to update the packaged version to the upstream version
> at commit.  But maybe it is not possible because the new upstream has
> changed some API or whatever breaking some dependants.

We can do that, and sometimes we do. I think we should avoid it when
possible, since it's rare that upstream projects intend for us to
distribute their development branches.

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

On Wed, 10 Mar 2021 at 12:09, Leo Famulari  wrote:

> However, I think it's more reliable to include the patches in Guix
> itself, and a lot easier for other packagers — including from other
> distros — to read them. I often look at what other distros have done
> when deciding how to fix things in Guix, and it's helpful when they
> don't make things too obscure.

In addition, I think it makes easier for long term support.  The source
should be archived in Software Heritage–work-in-progress.  If the
patches are not in the Guix repo, where are they if upstream disappears?


Cheers,
simon

Re: bsdiff package vulnerable to CVE-2020-14315

[Leo Famulari]

On Wed, Mar 10, 2021 at 09:49:57AM +0100, Léo Le Bouter wrote:
> A patch exists from FreeBSD: 
> https://www.freebsd.org/security/patches/SA-16:29/bspatch.patch - but
> it needs non-trivial porting since FreeBSD seems to have diverged in
> important ways from the source tree we use.
> 
> Debian, Fedora, Gentoo, Arch Linux, Void Linux, none have fixed this
> CVE yet due to missing readily usable patch.

Well, we could also just remove this package. It sounds like it is not
supported on Linux. Does it offer some unique functionality?

Re: Generate diff with git-diff and use in patches field of packages

[Leo Famulari]

On Wed, Mar 10, 2021 at 02:42:32PM +0100, zimoun wrote:
> If the package already uses git-fetch, why not directly uses the commit
> fixing the issue as source?

It's different to build from a Git commit vs to cherry-pick a single
commit.

Re: Generate diff with git-diff and use in patches field of packages

[Leo Famulari]

On Wed, Mar 10, 2021 at 04:11:34AM +0100, Léo Le Bouter wrote:
> Hello!
> 
> While patching packages for security issues, I often am needing to get
> some patches from git repos because upstream does not make releases.
> 
> Including patch in "patches" directory etc. is a bit troublesome, I
> would rather have some Scheme code do this with: upstream git url,
> commit selector range or not, with hash checking like origins.
> 
> Is that possible?

We do this sometimes. Check out how Bash is patched, and also the
vestigial qemu-patch procedure.

However, I think it's more reliable to include the patches in Guix
itself, and a lot easier for other packagers — including from other
distros — to read them. I often look at what other distros have done
when deciding how to fix things in Guix, and it's helpful when they
don't make things too obscure.

Re: Will 2021 be the year of build systems on gexps?

[Leo Famulari]

On Wed, Mar 10, 2021 at 03:12:42PM +0100, zimoun wrote:
> I do not think it interferes with the release since for now and except a
> big change, the plan is to release without the core-updates merge.
> Well, that’s my understanding of the previous discussion.

That's my understand as well.

Re: Release on April 18th?

[zimoun]

Hi Efraim,

On Wed, 10 Mar 2021 at 17:30, Efraim Flashner  wrote:
 
>> Does it make sense to merge wip-ppc64le and core-updates?
>> 
> I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
> which cherry-picked (I think) all of the powerpc64le commits and
> adjusted them to work against master WITHOUT affecting other
> architectures.
>
> I don't know why I thought it was an easy win, but if it looks good to
> everyone I don't see why we couldn't merge powerpc64le into master by
> the end of the week.

So you confirm that cherry-picking from core-updates (as I suggested
here [1]) is a bad idea, i.e., not an Easy Win™.  Anyway.

IIUC, the remaining part is the GCC upgrade, right?


1: <

Re: Release on April 18th?

[Efraim Flashner]

On Wed, Mar 10, 2021 at 02:27:47PM +0100, zimoun wrote:
> Hi Chris,
> 
> On Tue, 09 Mar 2021 at 10:17, Chris Marusich  wrote:
> > zimoun  writes:
> >
> >> Is it doable to have core-updates merged in the next weeks?  Or not at
> >> all.
> >
> > Do we plan to upgrade GCC?  This is required for the powerpc64le-linux
> > port; see below for details.
> 
> You mean replace gcc-7 by gcc-8 or greater, right?  It implies a
> core-updates merge, right?
> 
> 
> > The wip-ppc64le branch, which ports Guix to an architecture that can be
> > run on freedom-friendly POWER9 systems like the Talos II and Blackbird
> > from Raptor Computing Systems, is "almost" done, and I would really like
> > to try to get it into the next release if possible.
> 
> Could be cool!
> 
> > However, there is still some work to do, and I wouldn't necessarily want
> > to block the release just for sake of the powerpc64le-linux port.
> >
> > In fact, the wip-ppc64le branch was "fully functional" for a little
> > while.  By "fully functional," I mean that "make check" succeeded, "make
> > guix-binary.powerpc64le-linux.tar.xz" succeeded, the resulting binary
> > could be installed on a fresh Debian ppc64le system, the binary could
> > successfully build and run GNU Hello, and the binary could successfully
> > run "guix pull", and the newly installed "guix pull" could do the same.
> >
> > However, that was using glibc 2.31.  On core-updates, glibc has been
> > updated to 2.32, which unfortunately breaks wip-ppc64le.  To fix it, we
> > must upgrade GCC from 7 to 8 (or greater), and that is what we have done
> > on the wip-ppc64le branch (upgrade GCC to 8).  Currently, we are working
> > through build failures that occurred as a result, but I'm optimistic that
> > we can resolve those in the coming weeks.
> 
> Thanks for the explanations.
> 
> 
> > The real question, I think, is when do we plan to upgrade GCC on
> > core-updates?  It's still on GCC 7.5.0.  The powerpc64le-linux port will
> > require GCC 8 or greater, since core-updates is now using glibc 2.32.
> 
> Does it make sense to merge wip-ppc64le and core-updates?
> 

I wanted an Easy Win™ and I've pushed a branch wip-ppc64le-for-master,
which cherry-picked (I think) all of the powerpc64le commits and
adjusted them to work against master WITHOUT affecting other
architectures.

I don't know why I thought it was an easy win, but if it looks good to
everyone I don't see why we couldn't merge powerpc64le into master by
the end of the week.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Will 2021 be the year of build systems on gexps?

[zimoun]

Hi Ludo,

On Wed, 10 Mar 2021 at 12:09, Ludovic Courtès  wrote:

> The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being built,
> it can build ‘guix’ and cross-build things like ‘sed’:
>
>   
> https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp
>
>   https://ci.guix.gnu.org/jobset/wip-build-systems-gexp (though Cuirass
>   currently has unrelated problems)

Cool!

> In terms of performance, there’s still a ~10% slowdown when computing
> derivations compared to the ‘core-updates’ revision the branch is based
> on.

Less cool! :-)


> Here’s what I’d like to do in the coming days, if that doesn’t interfere
> with what others have in mind for the upcoming release:
>
>   • Monitor build failures due to typos/thinkos made while adjusting
> build systems;
>
>   • Merge on ‘core-updates’.

[...]

> That said, if people think it’s too late in the cycle, we could just as
> well keep it for the next cycle.

I do not think it interferes with the release since for now and except a
big change, the plan is to release without the core-updates merge.
Well, that’s my understanding of the previous discussion.


Cheers,
simon

Re: Generate diff with git-diff and use in patches field of packages

[zimoun]

Hi,

On Wed, 10 Mar 2021 at 04:11, Léo Le Bouter  wrote:

> While patching packages for security issues, I often am needing to get
> some patches from git repos because upstream does not make releases.

If the package already uses git-fetch, why not directly uses the commit
fixing the issue as source?

If the package is not already using git-fetch but instead url-fetch,
maybe the replacement to git-fetch makes sense.  Even if there is no
consensus about git-fetch vs url-fetch. :-) Thread here:




Cheers,
simon

Re: Release on April 18th?

[zimoun]

Hi Chris,

On Tue, 09 Mar 2021 at 10:17, Chris Marusich  wrote:
> zimoun  writes:
>
>> Is it doable to have core-updates merged in the next weeks?  Or not at
>> all.
>
> Do we plan to upgrade GCC?  This is required for the powerpc64le-linux
> port; see below for details.

You mean replace gcc-7 by gcc-8 or greater, right?  It implies a
core-updates merge, right?


> The wip-ppc64le branch, which ports Guix to an architecture that can be
> run on freedom-friendly POWER9 systems like the Talos II and Blackbird
> from Raptor Computing Systems, is "almost" done, and I would really like
> to try to get it into the next release if possible.

Could be cool!

> However, there is still some work to do, and I wouldn't necessarily want
> to block the release just for sake of the powerpc64le-linux port.
>
> In fact, the wip-ppc64le branch was "fully functional" for a little
> while.  By "fully functional," I mean that "make check" succeeded, "make
> guix-binary.powerpc64le-linux.tar.xz" succeeded, the resulting binary
> could be installed on a fresh Debian ppc64le system, the binary could
> successfully build and run GNU Hello, and the binary could successfully
> run "guix pull", and the newly installed "guix pull" could do the same.
>
> However, that was using glibc 2.31.  On core-updates, glibc has been
> updated to 2.32, which unfortunately breaks wip-ppc64le.  To fix it, we
> must upgrade GCC from 7 to 8 (or greater), and that is what we have done
> on the wip-ppc64le branch (upgrade GCC to 8).  Currently, we are working
> through build failures that occurred as a result, but I'm optimistic that
> we can resolve those in the coming weeks.

Thanks for the explanations.


> The real question, I think, is when do we plan to upgrade GCC on
> core-updates?  It's still on GCC 7.5.0.  The powerpc64le-linux port will
> require GCC 8 or greater, since core-updates is now using glibc 2.32.

Does it make sense to merge wip-ppc64le and core-updates?


Cheers,
simon

Re: 04/07: inferior: Break cached-channel-instance into two procedures.

[Mathieu Othacehe]

Hey,

> We need to keep ‘cached-channel-instance’ because it’s part of the
> public API and used outside Guix (in Guix-Jupyter at least).  We can use
> ‘define-deprecated’.
>
> Also, I think ‘cached-profile’ doesn’t quite capture what this is
> about.  :-)  The docstring should mention what COMMITS is.  The fact
> that INSTANCES is a thunk is a bit awkward and IMO not great for a
> public interface.
>
> WDYT?

Yeah you're right the abstraction is really not great. I'll tweak
Cuirass to use the existing API instead.

Reverted with: 8898eaec57f6294221888e6dca1802abdd3d5868.

Thanks,

Mathieu

Re: 05/07: inferior: Fix concurrent cached-profile calls.

[Mathieu Othacehe]

Hey Ludo,

> However, there’s already a (file-exists? cached) call a few lines
> above.  So what you need instead is a TOCTTOU-free ‘symlink’, along
> these lines:
>
>   (define (symlink/safe old new)
> (catch 'system-error
>   (lambda ()
> (symlink old new))
>   (lambda args
> (unless (= EEXIST (system-error-errno args))
>   (apply throw args)
>
>   ;; …
>
>   (define symlink*
> (lift2 symlink/safe %store-monad))
>
> WDYT?

Fixed with a831ff6bc3f92ab4ecf6135e4d6386f14189ad06.

Thanks,

Mathieu

Re: Will 2021 be the year of build systems on gexps?

[Julien Lepiller]

If we aim at merging c-u before next release, we should probably wait next 
cycle, as this introduces quite a lot of changes, and packages might break in 
subtle ways.

10% increase for computing derivations is not great :/ it already takes a long 
time to do that on my arm system ^^". I wonder how we could improve that?

Le 10 mars 2021 06:09:23 GMT-05:00, "Ludovic Courtès"  a écrit :
>Hello!
>
>Ludovic Courtès  skribis:
>
>> Over the last few days I’ve been head-down working on
>> ‘wip-build-systems-gexp’, the mythical branch that brings gexps to
>build
>> systems and packages, so we can say goodbye to
>> ‘build-expression->derivation’.  And… it’s quite a ride!
>
>The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being
>built,
>it can build ‘guix’ and cross-build things like ‘sed’:
>
>https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp
>
>  https://ci.guix.gnu.org/jobset/wip-build-systems-gexp (though Cuirass
>  currently has unrelated problems)
>
>In terms of performance, there’s still a ~10% slowdown when computing
>derivations compared to the ‘core-updates’ revision the branch is based
>on.
>
>Here’s what I’d like to do in the coming days, if that doesn’t
>interfere
>with what others have in mind for the upcoming release:
>
>  • Monitor build failures due to typos/thinkos made while adjusting
>build systems;
>
>  • Merge on ‘core-updates’.
>
>Then there are optimizations to work on, but that can take a bit
>longer.
>In particular, in ‘gexp->derivation’, allow file-like objects to be
>specified as environment variable values.  In turn, use that so that,
>say, ‘gnu-build-system’ has a single builder for all its packages and
>just calls ‘getenv’ to get the value of its various parameters, similar
>to what (guix git-download) does.
>
>That said, if people think it’s too late in the cycle, we could just as
>well keep it for the next cycle.
>
>Thoughts?
>
>Thanks,
>Ludo’.

Re: Will 2021 be the year of build systems on gexps?

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> Over the last few days I’ve been head-down working on
> ‘wip-build-systems-gexp’, the mythical branch that brings gexps to build
> systems and packages, so we can say goodbye to
> ‘build-expression->derivation’.  And… it’s quite a ride!

The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being built,
it can build ‘guix’ and cross-build things like ‘sed’:

  
https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp

  https://ci.guix.gnu.org/jobset/wip-build-systems-gexp (though Cuirass
  currently has unrelated problems)

In terms of performance, there’s still a ~10% slowdown when computing
derivations compared to the ‘core-updates’ revision the branch is based
on.

Here’s what I’d like to do in the coming days, if that doesn’t interfere
with what others have in mind for the upcoming release:

  • Monitor build failures due to typos/thinkos made while adjusting
build systems;

  • Merge on ‘core-updates’.

Then there are optimizations to work on, but that can take a bit longer.
In particular, in ‘gexp->derivation’, allow file-like objects to be
specified as environment variable values.  In turn, use that so that,
say, ‘gnu-build-system’ has a single builder for all its packages and
just calls ‘getenv’ to get the value of its various parameters, similar
to what (guix git-download) does.

That said, if people think it’s too late in the cycle, we could just as
well keep it for the next cycle.

Thoughts?

Thanks,
Ludo’.

Re: Joining the Guix family

[Ludovic Courtès]

Hi Lars,

Lars-Dominik Braun  skribis:

> today I’m joining the Guix family as a new committer. Some of you might
> know me already from guix-patc...@gnu.org or the last Guix Days in
> Brussels, which I also attended.

Woohoo, welcome on board!  :-)

Please double-check
, notably
the bit about the pre-push hook.

Cheers!

Ludo’.

Re: Implications of QEMU binfmt transparent emulation for builds

[Ludovic Courtès]

Hi Chris,

Christopher Baines  skribis:

> Anyway, something that's been on my mind regarding QEMU and builds is
> how well this matches up with building natively. In particular, I'm
> concerned that there are some derivations that will build on system A
> with some QEMU configuration allowing binaries for system B to be run,
> but won't build if that QEMU support wasn't there. I think there's also
> a chance that you could have a derivation for system A that builds on a
> system with QEMU support for system B, but then wouldn't build natively
> on system B.
>
> I think the first scenario is more likely, mainly because I wonder if
> this happens with cross built packages. If the package attempts to run
> software built for the target system, that will work if there's QEMU
> support there for that target system, but not if that QEMU support is
> lacking.
>
> This is just a theory at this point, I at least don't know of any cases
> of this happening, but I also haven't been looking. Any ideas?

We had concrete problems that manifested as CMake failing to find a
compiler when running emulated (emulated AArch64/ARMv7 on x86_64),
whereas it would find the compiler when running natively:

  https://issues.guix.gnu.org/43513

That’s the worst case: an issue showing up in emulated builds in a
deterministic fashion, and never happening on actual hardware.

Thanks,
Ludo’.

Re: GNU Guix (pull?) on i686 broke after zstd grafting

[Léo Le Bouter]

On Wed, 2021-03-10 at 11:37 +0100, Ludovic Courtès wrote:
> Hi Léo,

Hi Ludo!

> So I think there’s a genuine bug here.  Could you take a look?  At
> worst, we should skip the offending test on i686 (and perhaps
> ARMv7?).

I reported upstream and I got an answer, waiting for fix but also we
could do something based on their comment:

> So now that we have plausible explanation, what can be done about it
> ?
> 
> - Ignore this test. It's a just test error. Disable it.
> - Change the test, so that it passes. For example, use a fixed nb of 
> threads, like -T4.
> - Update the rule regulating -T0, determining automatically a nb of
> threads based on present nb of cores. Make it conditional for 32-bit
> systems, select a limit for this case (slightly more complex, will
> take time).
> - Update the thread-pool policy to allocate new threads only when
> needed, instead of up front (definitely more complex, will take even
> more time).

I am very tired now however, also not sure how to disable individual
tests there.

Léo


signature.asc
Description: This is a digitally signed message part

Re: I've rebased wip-ppc64le onto core-updates

[Efraim Flashner]

On Wed, Mar 10, 2021 at 11:17:02AM +0100, Ludovic Courtès wrote:
> Hi Chris,
> 
> Chris Marusich  skribis:
> 
> > I just wanted to let you know that I've rebased the wip-ppc64le branch
> > onto core-updates.  The wip-ppc64le branch head used to be
> > 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> > df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
> >
> > I wanted to inform you so you don't get caught off-guard the next time
> > you update your local copy.
> >
> > I've squished some commits together where it made sense to do so.  I've
> > omitted some commits which were cherry-picked before, but which are
> > already in the core-updates branch.  And I have explicitly NOT merged
> > master into wip-ppc64le at this time.
> 
> Noted.
> 
> > I have also taken the liberty of cherry-picking Tobias' commit
> > 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo to
> > .guix-authorizations.  This should allow him to add commits on
> > wip-ppc64le without worrying about causing problems for "guix pull"
> > later.
> 
> Good idea.
> 
> We’ll have to think about merging.  At things stand, it seems that the
> bits that could go to ‘master’ (those that don’t trigger a world
> rebuild) are already there, right?
> 
> For the rest, we could aim for rebasing on core-updates and merging
> there.
> 
> WDYT?

As noted in another thread this would involve updating gcc to gcc-8.
There are some other patches which could go straight into master (I'm
looking at libelf specifically, probably others), but glibc and
gcc/libstdc++ I'm not sure how to do those ones.

Actually, looking at the branch there's also findutils-boot0, but that
can be changed to only be for target-powerpc for now and changed in
core-updates. I have a similar one I had to do for binutils on
powerpc-linux that I managed to make not affect other architectures.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: GNU Guix (pull?) on i686 broke after zstd grafting

[Ludovic Courtès]

Hi Léo,

Léo Le Bouter  skribis:

> After commit: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=6f873731a030dd7ecbd8a5e756b38b26306f6966
>
> This happened:
> https://ci.guix.gnu.org/build/369538/details
>
> I made the commit, and not sure what to do here.
>
> The test suite seems to fail on i686..?

I’ve retried this i686-linux build and it seems to fail consistently:

--8<---cut here---start->8---
*** zstd command line interface 32-bits v1.4.9, by Yann Collet ***
(L3) Buffered :   0 MB - Consumed :   0 MB - Compressed :   0 MB => 0.00%
roundTripTest: datagen -g8M  | zstd -v19 -T0 --long | zstd -d19 -T0 --long

*** zstd command line interface 32-bits v1.4.9, by Yann Collet ***
Note: 48 physical core(s) detected
zstd: error 11 : Allocation error : not enough memory 
zstd: /*stdin*\: unexpected end of file
Files tmp1 and tmp2 differ
make[1]: *** [Makefile:329: test-zstd] Error 1
make[1]: Leaving directory '/tmp/guix-build-zstd-1.4.9.drv-0/zstd-1.4.9/tests'
make: *** [Makefile:90: shortest] Error 2

Test suite failed, dumping logs.
command "make" "check" "-j" "4" "CC=gcc" 
"PREFIX=/gnu/store/krx4mfj2yyg099kr1bj9pg0rs03fnymb-zstd-1.4.9" 
"LIBDIR=/gnu/store/la177xpxz00biapfhrrnx51pf1d9r8r3-zstd-1.4.9-lib/lib" 
"INCLUDEDIR=/gnu/store/la177xpxz00biapfhrrnx51pf1d9r8r3-zstd-1.4.9-lib/include" 
"HAVE_LZMA=0" "HAVE_LZ4=0" "HAVE_ZLIB=0" failed with status 2
builder for `/gnu/store/w0lbczib88vv83id42i2dx05v84fmpbv-zstd-1.4.9.drv' failed 
with exit code 1
build of /gnu/store/w0lbczib88vv83id42i2dx05v84fmpbv-zstd-1.4.9.drv failed
--8<---cut here---end--->8---

So I think there’s a genuine bug here.  Could you take a look?  At
worst, we should skip the offending test on i686 (and perhaps ARMv7?).

Thanks,
Ludo’.

Re: Getting the Guix Build Coordinator agent working on the Hurd

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

>> There are open questions as to what to include in the build environment:
>>
>>   https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/
>
> Isolation would be nice of course, although I'm not sure how much this
> will affect reproducibility, unless things are poking around in the
> store directly.

Lack of isolation is an immediate problem.  I was hopeful until we
stumbled upon an util-linux test failure; whether it fails depends on
what’s in the environment.

So I think isolation is not superfluous, which is annoying because it
means we pretty much have to address that before we can profit.

Ludo’.

Re: Getting rid of the mandb profile hook?

[Ludovic Courtès]

Hi Brice,

Brice Waegeneire  skribis:

> On 2021-03-03 15:13, Ludovic Courtès wrote:

[...]

>> I looked a bit at man-db, thinking it must have that already done
>> more
>> or less.  Indeed, one can run “mandb -uc” to create the database.
>> The problem is that it insists on writing databases and
>> ‘CACHEDIR.TAG’
>> files in the same directory as man pages.  In our case, these are all
>> read-only, so just prints a warning for each directory and keeps going.
>> It looks like man-db is not written with a situation like ours in
>> mind.
>
> What about using mandoc¹, the manpage compiler from OpenBSD, instead of
> man-db? As from it's manual it support specifying the database location:
>
> “makewhatis -d dir [file ...]”²
>
> It isn't packaged in Guix yet, but other Linux distros have done it,
> some
>  are even using it as their default.

Sounds like a plan!  We’d need to update the “Documentation” node in the
manual accordingly.

Do you want to give it a try?

>> [...]
>> One option I contemplated at one point is to simply have fewer man 
>> pages
>> in the first place.  :-)  There were packages that install man pages
>> when they shouldn’t.  This led to commits like
>> 305eefc0627eb1d047e6fc4320d7e56897719ab8 and
>> 4b797193d7508ddc53bb1ff7a267a0d50c1fe298 (and parent commits).
>
> More outputs would be great tho having a way to force the installation
> of
> specifics outputs for every installed package would improve quality of
> live.  For a specific example in that case, when installing ncurses from
>  the cli it would install it's man output too if you always want man
>  page
>  to be installed.

Hmm sounds tricky (and kinda unpredictable, too).

Thanks,
Ludo’.

Re: TOCTTOU race

[Ludovic Courtès]

Hi Maxime,

Maxime Devos  skribis:

> On Tue, 2021-02-23 at 16:30 +0100, Ludovic Courtès wrote:
>> Hi,
>> 
>> Maxime Devos  skribis:
>> 
>> > Is all addressed now? (Aside from the TOCTTOU.)
>> 
>> Yes, thank you!
>
> If all is addressed now, could you apply the patch?
> I don't see it in master yet and I don't have commit access.

Oops, sorry for the huge delay; I keep thinking that you already have
commit rights.  Anyway, I’ve applied it now and will push shortly.

Thanks!

Ludo’.

PS: Feel free to ping me or other committers on IRC next time.  :-)

Re: 04/07: inferior: Break cached-channel-instance into two procedures.

[Ludovic Courtès]

Hi Mathieu!

guix-comm...@gnu.org skribis:

> commit 7d63b775513e7049047222dbe403a4181f63828d
> Author: Mathieu Othacehe 
> AuthorDate: Fri Mar 5 09:51:42 2021 +0100
>
> inferior: Break cached-channel-instance into two procedures.
> 
> Break cached-channel-instance into two different procedures:
> channels->cached-profile and instances->cached-profile operating 
> respectively
> on channels and channels instances.
> 
> * guix/inferior.scm (cached-channel-instance): Rename it into ...
> (cached-profile): ... this new procedure.
> (channels->cached-profile, instances->cached-profile): New procedures.
> * guix/scripts/time-machine.scm (guix-time-machine): Adapt accordingly.

[...]

> -(define* (cached-channel-instance store
> -  channels
> -  #:key
> -  (authenticate? #t)
> -  (cache-directory 
> (%inferior-cache-directory))
> -  (ttl (* 3600 24 30)))
> -  "Return a directory containing a guix filetree defined by CHANNELS, a list 
> of channels.
> -The directory is a subdirectory of CACHE-DIRECTORY, where entries can be 
> reclaimed after TTL seconds.
> -This procedure opens a new connection to the build daemon.  AUTHENTICATE?
> -determines whether CHANNELS are authenticated."
> -  (define commits
> -;; Since computing the instances of CHANNELS is I/O-intensive, use a
> -;; cheaper way to get the commit list of CHANNELS.  This limits overhead
> -;; to the minimum in case of a cache hit.
> -(map channel-full-commit channels))
> -
> +(define* (cached-profile store instances
> + #:key
> + cache-directory
> + commits ttl)
> +  "Return a directory containing a guix filetree defined by INSTANCES, a
> +procedure returning a list of channel instances.  The directory is a
> +subdirectory of CACHE-DIRECTORY, where entries can be reclaimed after TTL
> +seconds.  This procedure opens a new connection to the build daemon."

We need to keep ‘cached-channel-instance’ because it’s part of the
public API and used outside Guix (in Guix-Jupyter at least).  We can use
‘define-deprecated’.

Also, I think ‘cached-profile’ doesn’t quite capture what this is
about.  :-)  The docstring should mention what COMMITS is.  The fact
that INSTANCES is a thunk is a bit awkward and IMO not great for a
public interface.

WDYT?

Thanks,
Ludo’.

Re: I've rebased wip-ppc64le onto core-updates

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> I just wanted to let you know that I've rebased the wip-ppc64le branch
> onto core-updates.  The wip-ppc64le branch head used to be
> 147b74817e6cf97f37090ecfd52e2588f4c39f7e, but now it's
> df5d633db7acf6389ca9d444b8f5784a0da5ac5d.
>
> I wanted to inform you so you don't get caught off-guard the next time
> you update your local copy.
>
> I've squished some commits together where it made sense to do so.  I've
> omitted some commits which were cherry-picked before, but which are
> already in the core-updates branch.  And I have explicitly NOT merged
> master into wip-ppc64le at this time.

Noted.

> I have also taken the liberty of cherry-picking Tobias' commit
> 65fb3a3eb9a759e3dba18e78113e80d7e5b353f4 from master, which adds Léo to
> .guix-authorizations.  This should allow him to add commits on
> wip-ppc64le without worrying about causing problems for "guix pull"
> later.

Good idea.

We’ll have to think about merging.  At things stand, it seems that the
bits that could go to ‘master’ (those that don’t trigger a world
rebuild) are already there, right?

For the rest, we could aim for rebasing on core-updates and merging
there.

WDYT?

Thanks,
Ludo’.

Re: guix environment --profile with --ad-hoc

[pkill9]

Hi,

> Can I ask: What is your use-case? Why not extend the existing profile
> using `guix package -p /path -i foobar`?

I'm making a script that uses guix containers for running applications
isolated from eachother, and I have a single profile for each
application. I want to be able to start the container in a shell for
debugging, and add packages to that session, such as coreutils, without
adding it permanently to the profile.

Re: Adding Substitute Mirrors page to installer

[raid5atemyhomework]

Hello,

Below I have a patch that adds a page for substitute mirrors.

Limitation is that the substitute mirror is only used after installation 
completes.  During installation the guix daemon still loads from the Berlin 
server.  Also, channel is still the default Guix channel (which is fairly slow 
as well from some places).

Testing done:

* Create an install image by `./pre-inst-env guix system image -t iso9660 
gnu/system/install.scm` on a patched Guix.
* Create a new VM and install using the created install image.
* Select the SJTU mirror.
* Complete installation (also notice that during install, the mirror is *not* 
used, which could be confusing to users).
* On installation completion, reboot VM, then `guix pull` on root.
* Check that `guix pull` gets substitutes from SJTU mirror.

The ability to also use the same mirror *during* install rather than after it 
would be very nice.  After all, the guix daemon has to be restarted during 
installation in the meantime anyway, so on restart it should be possible to 
switch the `substitute-urls`.  However the complications are:

* The `(gnu installer service)` module inherently assumes that services are 
completely orthogonal to everything else being configured in the installation.  
I'm not sure what the best way to extract the substitute mirror selection would 
be.
* The installation image has to do a local `guix system reconfigure` of itself 
so that its shepherd points the guix daemon to a new mirror, so that the guix 
daemon restart in `install-system` of `(gnu installer final)` will refer to a 
new mirror.

> I agree that we need a convenient way to add mirrors, it can be critical
> to users who get low throughput from Berlin.

Indeed.

>
> To that I'd add the option to add channels straight from the installer.
> Not sure it belongs to a separate change set, maybe we can hit two birds
> we one stone here.

If you mean mirrors of the official Guix channel, this would be nice.

However, channels are not described in the `operating-system` declaration.  
Thus, we need to create channel by extra mechanism in installer.  This can 
probably be done by hooking somehow into `install-final` as well, as it creates 
the `/mnt` mountpoint for installing.

If you mean other non-Guix channels, the only channels I know of that are not 
Guix cannot be named here, so --- are there any channels that *can* be named in 
official documentation about Guix?

Thanks
raid5atemyhomework

>From af7e4d1336ed9010a31011d2fbae2a27fdaca237 Mon Sep 17 00:00:00 2001
From: raid5atemyhomework 
Date: Wed, 10 Mar 2021 09:21:42 +
Subject: [PATCH] gnu: Add substitute mirrors page to installer.

* gnu/installer/services.scm (system-service) [snippet-type]: New field.
(%system-services): Add substitute mirrors.
(service-list-service?): New procedure.
(modify-services-service?): New procedure.
(system-services->configuration): Add support for services with
`'modify-services` snippets.
* gnu/installer/newt/services.scm (run-substitute-mirror-page): New
procedure.
(run-services-page): Call `run-substitute-mirror-page`.
---
 gnu/installer/newt/services.scm | 26 +-
 gnu/installer/services.scm  | 62 -
 2 files changed, 78 insertions(+), 10 deletions(-)

diff --git a/gnu/installer/newt/services.scm b/gnu/installer/newt/services.scm
index 74f28e41ba..0fd5d3f2de 100644
--- a/gnu/installer/newt/services.scm
+++ b/gnu/installer/newt/services.scm
@@ -92,6 +92,29 @@ client may be enough for a server.")
 (condition
  (&installer-step-abort)))

+(define (run-substitute-mirror-page)
+  (let ((title (G_ "Substitute mirror")))
+(run-listbox-selection-page
+  #:title title
+  #:info-text (G_ "Choose a server to get substitutes from.
+
+Depending on your location, the official substitutes server can be slow; \
+in that case, using a mirror may be faster.")
+  #:info-textbox-width 70
+  #:listbox-height 8
+  #:listbox-items (filter (lambda (service)
+(eq? 'substitute-mirror
+ (system-service-type service)))
+  %system-services)
+  #:listbox-item->text (compose G_ system-service-name)
+  #:sort-listbox-items? #f
+  #:button-text (G_ "Exit")
+  #:button-callback-procedure
+  (lambda _
+(raise
+  (condition
+(&installer-step-abort)))
+
 (define (run-services-page)
   (let ((desktop (run-desktop-environments-cbt-page)))
 ;; When the user did not select any desktop services, and thus didn't get
@@ -100,4 +123,5 @@ client may be enough for a server.")
 (run-networking-cbt-page)
 (if (null? desktop)
 (list (run-network-management-page))
-'()
+'())
+(list (run-substitute-mirror-page)
diff --git a/gnu/installer/services.scm b/gnu/installer/services.scm
index ec5ea30594..34d1e6f0de 100644

Re: 05/07: inferior: Fix concurrent cached-profile calls.

[Ludovic Courtès]

Hi Mathieu,

guix-comm...@gnu.org skribis:

> commit 6ee7e3d26b8f5d2a234518cc2ab1bfeba7cd7c18
> Author: Mathieu Othacehe 
> AuthorDate: Fri Mar 5 12:49:06 2021 +0100
>
> inferior: Fix concurrent cached-profile calls.
> 
> * guix/inferior.scm (cached-profile): Do not create the profile symlink 
> if it
> already exists.

[...]

> +++ b/guix/inferior.scm
> @@ -755,8 +755,9 @@ seconds.  This procedure opens a new connection to the 
> build daemon."
>  (built-derivations (list profile))
>  ;; Note: Caching is fine even when AUTHENTICATE? is false because
>  ;; we always call 'latest-channel-instances?'.
> -(symlink* (derivation->output-path profile) cached)
> -(add-indirect-root* cached)
> +(unless (file-exists? cached)
> +  (symlink* (derivation->output-path profile) cached)
> +  (add-indirect-root* cached))
>  (return cached))

It should be ‘munless’ instead of ‘unless’ since we’re in an ‘mbegin’.

However, there’s already a (file-exists? cached) call a few lines
above.  So what you need instead is a TOCTTOU-free ‘symlink’, along
these lines:

  (define (symlink/safe old new)
(catch 'system-error
  (lambda ()
(symlink old new))
  (lambda args
(unless (= EEXIST (system-error-errno args))
  (apply throw args)

  ;; …

  (define symlink*
(lift2 symlink/safe %store-monad))

WDYT?

Ludo’.

bsdiff package vulnerable to CVE-2020-14315

[Léo Le Bouter]

CVE-2020-14315

A memory corruption vulnerability is present in bspatch as shipped in
Colin Percival’s bsdiff tools version 4.3. Insufficient checks when
handling external inputs allows an attacker to bypass the sanity checks
in place and write out of a dynamically allocated buffer boundaries.

A patch exists from FreeBSD: 
https://www.freebsd.org/security/patches/SA-16:29/bspatch.patch - but
it needs non-trivial porting since FreeBSD seems to have diverged in
important ways from the source tree we use.

Debian, Fedora, Gentoo, Arch Linux, Void Linux, none have fixed this
CVE yet due to missing readily usable patch.

There may be a patch in Android or ChromiumOS source trees but if it is
present it is burried and not easy to find, also their tree probably
has diverged in non-trivial ways too.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Release on April 18th? (ppc64le support specifically)

[Efraim Flashner]

On Tue, Mar 09, 2021 at 10:32:18PM +0100, Vincent Legoll wrote:
> Hello Chris,
> 
> I'm all for that, what can I do to help ?
> 
> I don't have a Talos, though...
> 
> So only cross- or emulated- stuff...
> 
> Willing to help, but needs directions.
> 

The two ways forward that I can see is to figure out how to merge
wip-ppc64le into master without it affecting any of the other
architectures. This would generally be through some fancy ifs and whens
to only affect powerpc64le and would get the architecture supported
earlier.

For example, some of the patches touch gcc and libstdc++. If 'guix build
gcc-toolchain -d' and 'guix build gcc-toolchain -d
--system=powerpc64le-linux' are unchanged then you've successfully
combined the two.

The other option is to try to build and fix packages for other
architectures (notably x86_64 as a start) using the wip-ppc64le branch,
with the assumption that for the most part the same packages would be
broken by an update of gcc to gcc-8.

The first option has the potential to get powerpc64le merged before the
release, the second is going to be necessary in any event.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature