Re: secure boot

On 24-08-2022 05:07, Philip McGrath wrote: I could imagine a process like this: 1. Build the binary that needs to be signed. 2. Outside of the Guix build environment, create a detached signature for the binary using your secret key. 3. Add the detached signature to the Guix store, pe

Re: guix lint should support overrides

On 24-08-2022 10:08, zimoun wrote: Hi Vagrant, On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian wrote: But, because there is no way to silence a particular inappropriate suggestion from guix lint, it becomes noise, and each person evaluating the results of the package in the future then needs

Re: FSDG issues of SCUMMVM-based games

On 24-08-2022 22:24, Vagrant Cascadian wrote: Is it Functional Data: https://www.gnu.org/distros/free-system-distribution-guidelines.html "For example, some game engines released under the GNU GPL have accompanying game information—a fictional world map, game graphics, and so on—re

Re: FSDG issues of SCUMMVM-based games

On 24-08-2022 22:24, zimoun wrote: My understanding of the Debian argument is: 1. the licence is BSD-like respecting the Debian Free Software Guidelines 2. point #3 of DFSG [2] says «The license must allow modifications and derived works, and must allow them to be distributed under the s

Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS

On 20-04-2022 12:56, Zhu Zihao wrote: We may introduce following problems if we apply this solution. 1. Increase the closure size of LLVM. By default, if LLVM_BUILD_LLVM_DYLIB is set true, LLVM still tries to build the static archive. This may increase the closure size of LLVM. And some packag

Re: Clarify the license field of the package

On 22-08-2022 11:02, 宋文武 wrote: Hello list, I have some questions about the 'license' of a package, currently defined as: The license of the package; a value from ‘(guix licenses)’, or a list of such values. 1. It's the license of source files (guix build -S) or built binary file

antioxidant update: librsvg builds, and other things (core-updates)

Some updates: * core-updates is now targeted instead of master (because the librsvg on core-updates has a less complicated build system and hence easier to support with antioxidant) * librsvg now builds. It's about 3 times larger than the cargo-build-system librsvg (at least, the librs

Re: antioxidant update: librsvg builds, and other things (core-updates)

On 27-08-2022 21:54, Liliana Marie Prikler wrote:  * Due to how regularised the Rust build system is, it's feasible to compile tests even when cross-compiling (*), so cross-compiled could run the cross-compiled tests on the system they are cross-compiling for after the cross-compilation to veri

Re: antioxidant update: librsvg builds, and other things (core-updates)

On 28-08-2022 00:04, Liliana Marie Prikler wrote: Am Samstag, dem 27.08.2022 um 22:01 +0200 schrieb Maxime Devos: On 27-08-2022 21:54, Liliana Marie Prikler wrote: * Due to how regularised the Rust build system is, it's feasible to compile tests even when cross-compiling (*), so

Re: Guix Plover package issue

On 28-08-2022 19:44, Matt wrote: However, this fails on ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: python-plover: unbound variable Including (gnu packages stenography) doesn't resolve it. Using guix edit plover, I see that the definition is in gnu/packages/stenography.scm.

Re: usage of basu as requirement for sd-bus

On 30-08-2022 09:59, muradm wrote: Hello, basu is sd-bus library extracted from systemd. Currently, there are two packages depending on it, which are mako and grimshot. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56859, I suggest switching xdg-desktop-portal-wlr to basu. In very same i

Re: usage of basu as requirement for sd-bus

(**) This is just a guess about what your goal was, maybe you had a different reason in mind. E.g., basu seems to be more active than elogind. Oops I misread the dates -- the latest commit in basu was before the latest commit in elogind. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP

Re: usage of basu as requirement for sd-bus

On 30-08-2022 11:27, muradm wrote: IIUC, everything using basu also works fine with elogind (*), so the 'status quo' of still using elogind (for old and new) seems harmless to me (except for size -- basu is smaller). I don't find the "everything using basu also works fine with elogind" statem

Re: 04/04: gnu: Add fwupd.

On 01-09-2022 08:27, Reza Housseini wrote: > No, unless you're using a custom update protocol that fwupd does not > already support. The user guide[2] likewise states: > The OEM vendor is in full control over what models are supported and is > the only entity that can a

HTTP or HTTPS download URLs?

(guix gnu-maintenance) uses https://nongnu.freemirror.org/nongnu, whereas (guix download) uses http://nongnu.freemirror.org/nongnu/. This discrepancy causes my fix for to fail for the savannah updater. Can I just switch http -> https, or is there a reason for

Re: [PATCH v2] doc: Update contribution guidelines on patches, etc.

On 02-09-2022 15:12, Ludovic Courtès wrote: Hello, Liliana Marie Prikler skribis: * doc/contributing.texi ("Snippets versus Phases"): Replaced with... ("Modifying Sources"): ... this. List more use cases and some principles. It’s been a while; this looks like a nice improvement to me. It’

Re: Clojure & Maven Resolver packages

On 03-09-2022 17:38, Roman Scherer wrote: Hello Guix, I would like to enable the S3 transporter for the Clojure package. For this I need version 1.8.2 of the Maven Resolver packages. Right now we have version 1.6.3 packaged in Guix. AFAIK, you don't need to.  IIUC, the patch series at

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On 08-08-2022 23:51, Andreas Enge wrote: 20.4.5.3 Fixing technical issues (compilation errors, test failures, other bugs ...) Usually, a bug fix comes in the form of a patch copied from upstream or another distribution. In that case, simply adding the patch to the 'patches' field is the most con

Re: [PATCH v2] doc: Update contribution guidelines on patches, etc.

On 05-09-2022 11:47, Ludovic Courtès wrote: Hi, Maxime Devos skribis: On 02-09-2022 15:12, Ludovic Courtès wrote: Hello, Liliana Marie Prikler skribis: * doc/contributing.texi ("Snippets versus Phases"): Replaced with... ("Modifying Sources"): ... this. List mor

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On 09-08-2022 18:30, Maxime Devos wrote: the result of 'guix build --source' would be unusable on non-Guix systems, and also likely unusable on Guix systems of another architecture. --8<---cut here---end--->8--- The Oxford comma or

Re: [PATCH v2] doc: Update contribution guidelines on patches, etc.

On 05-09-2022 15:12, Maxime Devos wrote: On 05-09-2022 11:47, Ludovic Courtès wrote: Hi, Maxime Devos skribis: On 02-09-2022 15:12, Ludovic Courtès wrote: Hello, Liliana Marie Prikler skribis: * doc/contributing.texi ("Snippets versus Phases"): Replaced with... ("Mo

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On 07-09-2022 14:17, Andreas Enge wrote: Am Mon, Sep 05, 2022 at 03:03:34PM +0200 schrieb Maxime Devos: I meant 'snippet' in this subsubsection. Bugfixes seem useful to have in the result of "guix build --source", and appear to be required to be in there for the 'co

Re: Sanitizer of record fields?

On 08-09-2022 09:59, zimoun wrote: We could add a lint checker. Is it a “good” idea? We already have one, 'check-license'. Because lint is not always applied, a check should be done when running ’make’ or a special target. Is it a “good” idea? I suppose it is a possibility, but it adds a f

Re: how does antioxidant work?

On 08-09-2022 03:17, jgart wrote: Hi Maxime, how does antioxidant build system for rust work at a high level? https://notabug.org/maximed/cargoless-rust-experiments all best, There are two parts: * The actual build system (antioxidant.scm) -- it reads the Cargo.toml to see what the dep

Re: Sanitizer of record fields?

On 08-09-2022 13:16, zimoun wrote: Hi, On Thu, 08 Sep 2022 at 11:32, Maxime Devos wrote: On 08-09-2022 09:59, zimoun wrote: We could add a lint checker. Is it a “good” idea? We already have one, 'check-license'. Yeah, but I was talking about check if the field return the expec

Re: Sanitizer of record fields?

On 08-09-2022 13:35, b...@bokr.com wrote: Can geiser trace stuff? IWBN to have something analogous to bash's shopt for printing expression sources as they are read and/or executed. Does something like that exist? See: 'trace' in the Guile manual.  (This is a Guile feature, not a geiser featur

Re: Sanitizer of record fields?

On 08-09-2022 13:35, b...@bokr.com wrote: Hi Simon, et al On +2022-09-08 09:59:15 +0200, zimoun wrote: Hi, The website is currently failing [1] to build because a typo in some package declaration. The error message is not very helpful, srfi/srfi-1.scm:241:2: In procedure map:

Re: nix installed with guix on a foreign distro

On 27-07-2022 00:50, jgart wrote: What do you think Debian people should be providing to make it easier to run the guix installed nix package? Or, what should I ask the Debian people if I decide to inquire with them? all best, Right, you want to install "nix" (a distro) with "guix" (a dist

Re: nix installed with guix on a foreign distro

On 10-09-2022 04:02, jgart wrote: On Sat, 10 Sep 2022 02:45:46 +0200 Maxime Devos wrote: Worse, this is not just a service, but a distro. I mean that I want to run nix, the package manager, not the distro. Nix suffers from the holy trinity #~problem unlike Guix. #$https

Re: how does antioxidant work?

On 10-09-2022 16:50, jgart wrote: On Thu, 08 Sep 2022 12:03:36 +0200 Maxime Devos wrote: There are also some other small things with some checks for vendoring, #:test-options Cool! Will this build system support rust development with guix or it's only for packaging end user rust

Re: how does antioxidant work?

On 10-09-2022 19:38, jgart wrote: On Sat, 10 Sep 2022 18:17:50 +0200 Maxime Devos wrote: Caveat: the ‘examples’ and ‘benchmarks’ functionality is unlikely to be implemented by me (even though they may be useful for development) as they don't bring much value to Guix packaging. [inser

Re: Request: build package with source tarball

On 12-09-2022 03:04, Ryan Prior wrote: Hi there! Lately I've been testing distribution tarballs with a workflow like this: 1. update some software in my source directory 2. create a distribution tarball 3. untar to a directory like /tmp/mypkg-src 4. run: |guix build --with-source=mypkg=/t

Re: Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

On 13-09-2022 15:50, John Kehayias wrote: Normally I would just go with the latest cbindgen to have that for future uses, but maybe we should just have 0.23 and 0.24? I have patches for both, just trying to see what would be cleanest here. From what I've heard (and experienced in antioxidan

Re: Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

On 13-09-2022 16:35, John Kehayias wrote: I think you missed the earlier part where I linked to an upstream bug for building some versions of firefox with cbindgen > 0.23. Oops, yes. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digi

Re: substitute derivation: also substitute grafts?

On 15-09-2022 16:46, Csepp wrote: Ricardo Wurmus writes: [...] Did I say *all items*? Well, … grafts are not included, because graft derivations are marked as not substitutable. Can we change that conditionally? I would really like to avoid having to build grafts on B when they have alread

Re: substitute derivation: also substitute grafts?

On 15-09-2022 19:43, Csepp wrote: Could we store the offsets of references somewhere at build time? I now remember that idea, I forgot about that one. My answer: I don't see why not, maybe by adding a phase to %standard-phases (at the very end, to avoid it becoming invalid) that saves it i

Re: Updating minetest to 5.6.0?

On 15-09-2022 19:59, Jan wrote: Hello, I almost effortlessly updated the minetest package to 5.6.0 so I wonder if there's a person who is in charge of updating minetest-related stuff or should I just send the patch? No, Guix does collective maintenance, and AFAIK nobody has made a patch y

Re: Updating minetest to 5.6.0?

On 16-09-2022 00:45, Jan wrote: The minetest-mod-build-system has some (very basic) tests for testing that the mods at least load with the new Minetest. About that, I can never see mods installed with Guix in Minetest. Is the build system really working as intended? I'm running the latest Gui

Re: Updating minetest to 5.6.0?

On 16-09-2022 19:57, Jan Wielkiewicz wrote: Last one question before sending the patches: I'm adding a minetest game called Exile and it uses a mod called naturalslopeslib. I packaged both of them but Exile expects the lib to be installed in "/.guix-profile/share/minetest/games/exile/mods/natur

Re: Updating minetest to 5.6.0?

On 17-09-2022 02:10, Jan Wielkiewicz wrote: Done. See the patches (I can't really find "git send-email" on Guix for some odd reason). The hacks in the Exile package are quite ugly, but I don't know a better way, see below. Try "guix show git", it will mention a 'send-email' output that you

Re: Updating minetest to 5.6.0?

On 17-09-2022 02:13, Jan Wielkiewicz wrote: Forgot the patches... Some problems (1) a single package per patch (minetest-naturalslopeslib can be done in a commit before minetest-exile) (2) no superfluous version prefixes -- remove the "v" from (version "v0.3.8") and replace (commit ver

Re: Stumpwm Contrib Packages

On 11-09-2022 17:02, Trev wrote: Hey Guix, I am trying to decide whether or not to contribute a refactor of stumpwm-contrib in gnu/packages/wm.scm. It feels like each contrib module should be its own package with its own checkout and that it might be a bad idea to update all of the contrib mod

Re: Store Functor and Store Applicative

On 18-09-2022 16:51, jgart wrote: Hi Guixers, Why does Guix implement a monad but not a functor and an applicative? To my knowledge: Functor: all monads are automatically functors, if someone would like a functor interface, they can implement 'lift' and 'fmap' when needed. There just hasn

Re: What 'sh' should 'system' use?

On 19-09-2022 02:13, Philip McGrath wrote: 1) If we want to continue to hard-code a specific shell into Glibc, We do, for reproducibility -- otherwise, the behaviour of the 'system' function depends on whatever is the current /bin/sh, and sometimes /bin/sh is updated (and on some foreign sy

Re: substitute derivation: also substitute grafts?

On 19-09-2022 18:26, Josselin Poiret wrote: Hi everyone, Maxime Devos writes: Fallbacks might be necessary (not every store item is constructed from a package), but it all sounds doable and efficient. Also the union could needs to be modified to ignore the .graft-offsets of the union&#x

Re: git guix checkout automation for contributors

be incorrect on the top-level of the Guix source tree more explicitly: Maxime Devos wrote: Guix itself doesn't follow this convention: the guix source tree has an unrelated "guix.scm" file, that doesn't evaluate to a package. I'd expect that running "guix shell&qu

Re: What 'sh' should 'system' use?

On 26-09-2022 09:04, Philip McGrath wrote: [...] (Very occasionally, a program really does want to invoke the shell, such as when shell expansion is part of an existing API.) From a different perspective, this is part of why I've recently been thinking we should find 'sh' dynamically: most pro

Re: Guix System For Kids

On 02-10-2022 21:32, jgart wrote: What do people think of having an education distro for kids? Similar to these: https://itsfoss.com/educational-linux-distros/ Could we use that Guix GUI written in smalltalk to get started? Going by what I'm seeing on that page, in many cases 'education d

Re: Planning for a release, for real

On 06-10-2022 16:50, Ludovic Courtès wrote: Hello Guix! Will Guix’s 10th year be a release year? I hope so! We need to plan and coordinate. Releases have to be a group effort; some of the most important work won’t be coding but coordination. Coordination is key. I don’t think I should be spe

Re: system/package testing?

On 06-10-2022 17:51, Simon Josefsson via Development of GNU Guix and the GNU System distribution. wrote: Hi Is there any infrastructure to run a system-wide test suite, or at least a per-package test suite? There's "make check-system", for system services (and implicitly, for the software

Re: system/package testing?

On 06-10-2022 20:34, Maxime Devos wrote:  -- I miss Nevermind this, just some writing error during composing the message OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

Re: Planning for a release, for real

On 07-10-2022 11:50, Ludovic Courtès wrote: Hi, Maxime Devos skribis: I have some unapplied security patches (from before the latest release (1.3.0) (!)) (more precisely, some patches that prepare for actually being able to write the security patches, once the preparation patches are

Re: Small change request to the manual page "Building from Git"

On 06-10-2022 15:35, Mehmet Tekman wrote: Hi there, I'd like to request some small changes be made on this page: > https://guix.gnu.org/manual/en/html_node/Building-from-Git.html 1. Authenticating on a foreign distro When at

Re: Small change request to the manual page "Building from Git"

blem. However, --pure appears to have been added for a reason (commit 43ec98ef3025f67ff4f66b7da0bcb79a6f088042), so I expect the solution is to rephrase things somehow (maybe something about running "guix git authenticate" outside "guix shell -D guix"). On Sun, 9 Oct 2022 at 11:08, Maxime Devos w

Re: Small change request to the manual page "Building from Git"

On 10-10-2022 18:18, Mehmet Tekman wrote: Sorry for the message duplication, it's the default with my email provider. If "guix shell -D guix --pure" is included in the new version of the manual, then I'm more than happy to drop my suggestion. Thanks for the extra context, and the general tips!

Re: crate importer throws

On 11-10-2022 23:39, jgart wrote: ``` λ guix import crate the-way ;;; Failed to autoload string->semver-range in (semver ranges): ;;; no code for module (semver ranges) Backtrace: In ice-9/boot-9.scm: 1752:10 9 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 8 (a

Re: crate importer throws

On 12-10-2022 17:50, jgart wrote: On Wed, 12 Oct 2022 14:24:26 +0200 Maxime Devos wrote: That still throws: guix shell guile-semver -- guix import crate the-way [...] WDYT I think you need to add 'guile' as well (profiles don't properly compose yet w.r.t. search paths):

Re: crate importer throws

On 15-10-2022 01:35, Csepp wrote: of PGP Signed Part]] [...] This works without adding guile: guix shell --pure guile-semver -- "$(which guix)" import crate the-way Any idea why? I didn't add guix to the shell because I wanted it to use the same guix profile. "guix shell --pure guile-semver

Re: crate importer throws

On 12-10-2022 23:51, Csepp wrote: And yes, the error message could be clearer, although I'm not sure where that should be fixed. How about in the Guix code that uses the semver stuff? Guile doesn't know what packages correspond to what modules and it should probably stay that way. It does

Re: Questions about Cuirass

On 20-10-2022 23:19, James Hobson wrote: Hello! Currently evaluating guix for embedded systems at work. But I have a few questions that I can’t quite work out from the docs. Please feel no obligation to answer! Please note that my guix journey is at its very beginning. I’ve not even had a go

Re: bug#58859: profile contents depends on package order

Looks sort-of but not quite a duplicate of (‘guix shell’ skips profile collisions checks) to me. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

Antioxidant (new rust build system) update - 100% builds

Hi, 100% (rounded up) of the packages build with antioxidant, though a very few still fail to build: . So far, work on antioxidant has been done in a separate channel for convenience, but given that almost everything builds now, I think it's a g

Re: Questions about Cuirass

On 30-10-2022 13:50, James Hobson wrote: Sorry for not getting back to you. Looks promising! I wish I could release everything under a free license. Baby steps though! I’ve managed to release a few things under LGPL since I started! That’s 100% more than before! Sounds good. But anyway.

Re: Antioxidant (new rust build system) update - 100% builds

On 02-11-2022 12:20, Ludovic Courtès wrote: [. ..] That’s but it probably needs work if we want it to work reliably on all the packages. My understanding is that we’d need a “flag day” where we’d switch all Rust packages to Antioxydant in one commit, is that c

Re: Antioxidant (new rust build system) update - 100% builds

On 03-11-2022 16:16, Ludovic Courtès wrote: Hi, [...] Perhaps we could temporarily support the “old style”, using the run-time transformation currently in your repo? That would allow third-party channels to migrate peacefully, and it would also reduce the likely hood of breakage during transiti

Re: Packaging: Need some help replacing a check phase

On 26-12-2022 17:15, Luis Felipe wrote: Hi, I'm packaging a Guile software but the package fails to build when I try to replace the check phase, and I can't see what I'm doing wrong. As mentioned by Kaelyn, guile-build-system doesn't have a check phase to replace. The patch series at

Re: UTF-8 progress bar

On 28-01-2023 14:17, Julien Lepiller wrote: Hi Guix! I have a patch waiting (https://issues.guix.gnu.org/59975) that will change progress bars to use some unicode characters. I think they look better, but I'm a bit afraid they might not look right on some config, so I'd like to know if your te

Re: guix lint false positives and RFC patch

On 28-01-2023 22:07, Vagrant Cascadian wrote: The other thing I remember being caught up on, which was not a deal-breaker, per se, was hoping for a way to loop through a bunch of @SOMETHING things ... I was not happy with: +(if (>= (string-length (string-replace-substring +

Re: Reducing useless module imports

On 03-02-2023 18:11, Julien Lepiller wrote: gnu packages minetest) imports (guix build-system minetest) but never uses the minetest-build-system. (gnu packages abiword) uses (guix build-system gnu) but does not use the gnu-build-system. The build-system minetest-build-system does not exist;

Re: Merging core-updates?

On 15-02-2023 19:51, Andreas Enge wrote: I am trying to build openjdk13 without the patch as follows: (define-public openjdk13 (make-openjdk openjdk12 "13.0.13" "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji" (source (origin (method git-fetch)

Re: intrinsic vs extrinsic identifier: toward more robustness?

Op 03-03-2023 om 19:07 schreef Simon Tournier: Hi, I would like to open a discussion about how we identify the source origin (fixed output). It is of vitally importance for being robust on the long-term (say 3-5 years). It matters in Reproducible Research context, but not only. # First thin

Re: intrinsic vs extrinsic identifier: toward more robustness?

Op 05-03-2023 om 21:21 schreef Simon Tournier: Whatever the intrinsic identifier we consider – even ones based on very weak cryptographic hash function as MD5, or based on non-crytographic hash function as Pearson hashing, etc. – the integrity check is currently done by SHA256. How about using

Re: [GSoC 23] distributed substitutes, cost of storage

Op 25-03-2023 om 20:00 schreef Attila Lendvai: welcome on board Anand! In case a user requests for a substitute and there is a missing block in the decoding process, a HTTP request for block would sent to the substitute server and the server will encode the corresponding block in real time a

Re: [GSoC 23] distributed substitutes, cost of storage

Op 04-04-2023 om 12:53 schreef Attila Lendvai: Onderwerp: Re: [GSoC 23] distributed substitutes, cost of storage Van: Attila Lendvai Datum: 04-04-2023 12:53 Aan: Maxime Devos CC: Vijaya Anand , pukkamustard , guix-devel@gnu.org it's another question whether this mirroring shou

Re: rust-build-system from antioxidant

Op 02-06-2023 om 20:02 schreef Nicolas Graves: A few months ago, Maxime Devos worked on a new rust-build-system to handle a few issues we were experiencing with cargo (see discussions on antioxidant in guix-devel). A month ago, we discussed about the possibility of the integration in core guix

Re: rust-build-system from antioxidant

Op 12-06-2023 om 03:17 schreef Maxim Cournoyer: Hi Maxime, Maxime Devos writes: Op 02-06-2023 om 20:02 schreef Nicolas Graves: A few months ago, Maxime Devos worked on a new rust-build-system to handle a few issues we were experiencing with cargo (see discussions on antioxidant in guix

Re: rust-build-system from antioxidant

Op 12-06-2023 om 15:05 schreef Maxim Cournoyer: Hi Maxime, Maxime Devos writes: Op 12-06-2023 om 03:17 schreef Maxim Cournoyer: [...] Yes. Overruling is a form of blocking, and blocking by authority (whether de facto or de jure) is overruling. There should not be a notion of 'overr

Re: An idea regarding Guix Profiles

to install. (It doesn't make sense to install multiple bootloaders after all). Thoughts? Maxime -- Maxime Devos PGP Key: C1F3 3EE2 0C52 8FDB 7DD7 011F 49E3 EE22 1917 25EE Freenode handle: mdevos signature.asc Description: This is a digitally signed message part

Re: Potential security weakness in Guix services

Hi Guix, On Thu, 2021-01-28 at 16:53 -0500, Leo Famulari wrote: > On January 19 2021, we received a message from Maxime Devos describing a > potential attack vector on Guix System. > > If an attacker can exploit a remote code execution vulnerability (RCE) > in a program used by

Re: Potential security weakness in Guix services

On Fri, 2021-01-29 at 14:33 +0100, Maxime Devos wrote: > Hi Guix, > [...] > > Below is a summary of their messages, including a mitigation proposal. > > Your feedback is requested! > > I'm writing a patch right now. It's a little more elaborate than my >

Re: Bring KDE into Guix easily

On Sun, 2021-01-31 at 17:15 +0100, Hartmut Goebel wrote: > Hello everybody, > > are you interested in getting KDE into Guix? > Not much of a KDE user myself (except kcachegrind, a drawing application I forgot the name of and manuskript), but more packages are nice! > I prepared a repo providing

Re: Potential security weakness in Guix services

> > I’m not sure I understand the threat model. If Knot has a RCE > > vulnerability, it can be exploited to run anything on behalf of the > > ‘knot’ user. > > > > At that point, all the state associated with Knot in /var/lib should be > > considered tainted; new keys should be generated, and so o

Re: Potential security weakness in Guix services

On Tue, 2021-02-02 at 14:07 +0100, Ludovic Courtès wrote: > OK, I see. Roughly, this symlink chown story would be a local exploit > that the attacker can take advantage of after exploiting the RCE to > potentially get root access. > > ‘mkdir-p/perms’ could check that the directory is not a symlin

Re: Potential security weakness in Guix services

> I'll look into writing a concrete proposal for *at in guile. > I'll post a link to the guile mailing list message when it has > been composed and sent. Here it is: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46258 I'm not familiar with guile's code base and conventions and my TODO list is ever-

Re: Installing a wrapper guile script in /bin

> Say I have a script that reads /proc/cpuinfo and runs my executable with the > correct flags to load the library with the best CPU features possible. How can > I embed such a script in the package definition (as a gexp?) and install it > under /bin/? Let's presume the binary is called $X. What

Re: Installing a wrapper guile script in /bin

> The script contents are not what I'm confused about. I don't know how to turn > my gexp script into a file under /bin/. This is conceptually what I want: > > (package > (name "foo") > ... > (arguments >`(... > #:phases > (modify-phases %standard-ph

Re: Installing a wrapper guile script in /bin

> Anyway, thanks for the pointers! They motivated me to keep pushing until > something worked. Glad I could help you! signature.asc Description: This is a digitally signed message part

Re: Emacs and URLs in Git commit messages

On Thu, 2021-02-04 at 00:38 -0800, Chris Marusich wrote: > Regarding the URL, do people just type it all out, including the opening > and closing brackets (<>)? Or is there an Emacs command that does it > for you? I've briefly looked on the Internet, but this is the kind of > thing that seems dif

Re: Potential security weakness in Guix services

On Fri, 2021-02-05 at 10:57 +0100, Ludovic Courtès wrote: > Hi Maxime, > > > I don't know how I should implement this properly in Guile, though. > > In C, I would use loop using openat with O_NOFOLLOW, in combination > > with stat, but Guile doesn't have openat or O_NOFOLLOW. > > In this case we

Re: Potential security weakness in Guix services

On Fri, 2021-02-05 at 13:20 +0100, Maxime Devos wrote: > On Fri, 2021-02-05 at 10:57 +0100, Ludovic Courtès wrote: > > [...] > [...] > > I'll try to implement this API in Scheme (using the FFI), and post > it at https://notabug.org/mdevos/things. I'll post a

Re: Potential security weakness in Guix services

On Sat, 2021-02-06 at 22:28 +0100, Ludovic Courtès wrote: > Maxime Devos skribis: > > I just remembered this subtlety: during bootup, the activation code is > evaluated by the Guile that’s in the initrd, which is a > statically-linked Guile, and thus we can’t use ‘dynamic-link’ &

Re: ZFS on Guix

Hi raid5atemyhomework, I can't help you with ZFS, but I think I've found some small issues with the configuration file: * the shepherd services defined in `configuration.scm` seem one-shot services to me, so maybe add '(one-shot? #t)'. * in the 'stop' of zfs-automount, the code changes the wor

Re: ZFS on Guix

On Mon, 2021-02-08 at 09:32 +, raid5atemyhomework wrote: > > * the shepherd services defined in `configuration.scm` > > seem one-shot services to me, so maybe add '(one-shot? #t)'. > > I was wary of making the `zfs-scan` one-shot, since there is a dependent > service on top of it. Not to m

TOCTTOU race (was: Potential security weakness in Guix services)

heck-system TESTS="basic cups"'. I couldn't test all affected services, unfortunately, due to lack of system tests. Thoughts? Greetings, Maxime. From ad10c577eb1f13b9b66ea387648671df33b869d7 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 14 Feb 2021 12:57:32 +0100 S

Re: TOCTTOU race

use-module. This should be corrected now. Please take note that I didn't correct all potentially insecure activation gexps. These should ideally be done by someone who knows how to use the particular service and have a system to test it on. (My changes to nscld-service-type and knot-activ

Re: TOCTTOU race

Aside from the TOCTTOU.) Maxime. From 395208e1e8e1ab6dd3eb5739b2726f06a49e0041 Mon Sep 17 00:00:00 2001 From: Maxime Devos Date: Sun, 14 Feb 2021 12:57:32 +0100 Subject: [PATCH] services: Prevent following symlinks during activation. This addresses a potential security issue, where a compromised

Re: TOCTTOU race

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

Re: Commit pushed to master with unauthorised signature

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

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

On Tue, 2021-03-16 at 15:29 -0400, Leo Famulari wrote: > > [...] > > No, sorry :) Someone else (maybe an i686 user?) will have to find the > time to test it. I haven't tried the patch, but note that x86-64 systems are also i686 systems, so users of x86-64 systems can try ./pre-inst-env guix bu

Re: A Critique of Shepherd Design

On Fri, 2021-03-19 at 17:33 +, raid5atemyhomework wrote: > GNU Shepherd is the `init` system used by GNU Guix. It features: > > * A rich full Scheme language to describe actions. > * A simple core that is easy to maintain. > > However, in this critique, I contend that these features are bugs

<    1   2   3   4   5   >