Re: policy for packaging insecure apps
Hi Attila, Attila Lendvai writes: > the context: > > > there's an app currently packaged in guix, namely > gnome-shell-extension-clipboard-indicator, that has a rather questionable > practice: by default it saves the clipboard history (passwords included) in > clear text, and the preferences for it is called something obscure. its > author actively defends this situation for several years now, rejecting > patches and bug reports. Are there no forks yet? [...] > my question: > > > how shall we deal with a situation like this? > > 1) shall i create a guix patch that makes the necessary changes in > this app, and submit it to guix? this would be a non-trivial, and > a rather hidden divergence from upstream, potentially leading to > confusion. Perhaps enough people are interested in getting this in order to have created a fork already? We could use it. > 2) is there a way to attach a warning message to a package to explain > such situations to anyone who installs them? should there be a > feature like that? should there be a need for a --force switch, or > an interactive y/n, to force installing such apps? For now, I think a simple mention of the issue in the description could be enough. > 3) is there a point where packages refusing to address security > issues should be unpackaged? and also added to a blacklist until the > security issue is resolved? where is that point? would this one > qualify? Is the issue is severe enough (I don't think it is the case here -- it seems a note to its description would be sufficient -- but I haven't looked closely into it), I think the package could be dropped, discussed as a patch. > 4) is this the responsibility of a project like guix to address > situations like this? When the security risks introduced are severe, I'd say so (by excluding such package from our collection) -- but it would need to be something truly problematic. -- Thanks, Maxim
Re: Python's native-inputs
Hi Nicolas, Nicolas Graves via "Development of GNU Guix and the GNU System distribution." writes: > Hi Guix, > > On some languages, there are a lot of unused native-inputs that are > development & linting dependencies much more than packages that are > actually used to build or test a package (I'm thinking at least Python > and Rust). These fall in the category of tools "useful" at run time, but > unecessary at build time. Indeed. > Is there a clear policy about their removal? I've seen the case of > pre-commit in Python, and I've commited a series yesterday regarding > pylint, but there are a whole lot of them in Python, at least : [...] > These packages make a lot of sense when considering things like > `guix shell -D` but they are hampering some progress on Python packages > since they are everywhere and a small update in their inputs rebuilds > the whole python world (even though it has NO influence on the > functionality of any other package). > > What are the guidelines in this case? There aren't really any guidelines. It's easy to avoid the linters, it makes sense to avoid them, but sometimes upstream makes it difficult to avoid running a linter as part of there test suite, in which case I think it's acceptable to keep them as native-inputs rather than come up with more patches to maintain. > I can propose a huge patch series (currently ~300 patches, and not > finished), to remove them, lint against them and remove them from the > importer as a default, but that's a big decision to make. IMO we should > have a dev-inputs field to handle these cases, but that's even more work. The situation is similar as for other test inputs such as pytest; it has an enormous amounts of dependents and thus cannot be easily upgraded on the master branch. At least more up-to-date variants can be added since these are not in the transitive closure of any packages. I don't think we should go out of our way to address annoyances that upstream have caused -- that'd be too much work to maintain in the long run. -- Thanks, Maxim
Re: Should we include nss-certs out of the box?
Hello, Ludovic Courtès writes: [...] >> It apparently even makes it impossible to run 'guix pull', if I am to >> believe bug#62026. > > I don’t think that’s the case: see use of ‘le-certs’ in (guix scripts > pull). OK, good to know! > >> Should we do as in bug#62026 and have this package be part of the >> recommended basic installation? It'd be in the basic set of an >> operating-system packages (via its default %base-packages set). It >> could still be manipulated via the Guix API (filtered out/replaced with >> something else). >> >> Is anyone opposed to having nss-certs in %base-packages? > > No objection from me. I’m partly responsible for the initial choice to > not include nss-certs by default, but as you write, most likely everyone > installs it these days. > > Note that we’ll also need to remove that choice from the installer in > (gnu installer services). I went ahead and have now done so, and included a news entry for it. I've adjusted the OSes templates accordingly, the doc, and the installer in 65e8472a4b6fc6f66871ba0dad518b7d4c63595e. Let me know if I've missed anything. -- Thanks, Maxim
Re: 01/06: gnu: gnurl: Deprecate in favor of curl.
Hi Ludo, Ludovic Courtès writes: > Hi, > > guix-comm...@gnu.org skribis: > >> +(define-deprecated/public-alias gnurl curl) > > Just for the record (because it probably doesn’t matter much in this > case), this creates a deprecated alias for the variable, but not for the > package. > > For package deprecation, I think it’s best to write: > > (define-public gnurl (deprecated-package "gnurl" curl)) > > to allow “guix install gnurl” to DTRT. Deprecating the variable itself > is usually less important for packages. Ugh. I always spent some minutes looking at the docstring and they are too general/vague to be of much practical use, at least to me, and I often manage to get it wrong, as I did here! I tried to follow-up with the recommended '(define-public gnurl (deprecated-package "gnurl" curl))' alternative, but it seems I'm not hitting a Guile module top-level dependency cycle, as it won't byte compile, erroring with: --8<---cut here---start->8--- ice-9/eval.scm:293:34: error: curl: unbound variable --8<---cut here---end--->8--- Indeed, deprecated-package works by inheritance, so according to our guidelines defined in (info '(guix) Cyclic Module Dependencies'), it should be defined in the curl module. I've now done so in commit a69e5e5e47b70e3fe14040142544147fbd9239a1. > As I write this, I realize we should probably document package > deprecation and removal. This would greatly help, and/or extended docstrings with practical examples at the definition sites. -- Thanks, Maxim
Distributed GNU Shepherd NLNet Grant
Dear comrades, As some of you already know, in December I submitted an application for an NLNet grant to fund porting our beloved Shepherd to Spritely Goblins [1]. This work would represent a radical evolution in the capabilities of not just Guix's system layer, but of GNU/Linux system layers in general; and would also be the biggest real-world test to date of the Goblins library and its capabilities (pun not intended). Materially, it would allow Shepherd dæmons running on different machines to securely communicate and interact with each other, going so far as to control one machine's dæmons from another machine. I am happy to announce that this grant application was approved! [2] While there remain some administrative tasks to complete before work can begin, I wanted to make the community aware of this upcoming effort and to invite you all to collaborate in this process. My hands may be the ones on the keyboard, but I want this to be a community project. I welcome questions and feedback about the project's goals and direction. You can learn more about object-capability security, the basis of Goblins, from Spritely's "The Heart of Spritely" whitepaper [3] as well as erights.org (which the whitepaper cites heavily). You can learn more about Goblins and this specific project at the links cited above. Thank you to everyone who supported the application process. Ludo, I wouldn't have the courage to attempt this if I didn't know I have your support. Also, this grew from your idea of integrating Goblins and the Shepherd in the first place. Christine, I couldn't do this at all if not for your and Spritely's work, and I wouldn't have applied for this grant without your encouragement. Thank you as well to everyone who's talked with me about this project, shared ideas and excitement, or just not gotten mad at me for emailing them questions out of the blue - I'm sure you know who you are. Knowing the community supports this work only increases my desire to do it. Last but most assuredly not least, thanks to NLNet for funding this project. Y'all are an incredible positive force in free software and thereby the world. Keep up the good work! I look forward to working together with all of you over the coming months! Solidarity, Juli [1] https://spritely.institute/goblins/ [2] https://nlnet.nl/project/DistributedShepherd/ [3] https://spritely.institute/static/papers/spritely-core.html
Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)
On Tue, 16 Apr 2024 08:43:23 +0200 pelzflorian (Florian Pelz) wrote ---
> Hi Matt. When triple checking, I read in “info "(texinfo)@pxref"”:
>
>In past versions of Texinfo, it was not allowed to write punctuation
> after a '@pxref', so it could be used _only_ before a right parenthesis.
> This is no longer the case. The effect of '@pxref{NODE-NAME}' is
> similar to that of 'see @ref{NODE-NAME}'. However, in many circumstance
> the latter is preferrable, as this makes it clear in the Info output
> that the word "see" should be present.
>
> Because of this last sentence, my tendency would now be to use @pxref
> only for parentheses. (Texinfo is really confusing.) Should I just cut
> these changes:
>
> (Linux Services): Use @pxref to start phrase.
> (Configuring the Shell): Use @pxref to start phrase.
Yes, I agree that cutting those, and using the original "see @ref{}", is what
the Texinfo manual says is correct. We should also cut this change:
(Setting Up the Daemon): use @xref to start sentence.
The original was also correct.
The only change that should remain is:
(Build Systems): capitalize "python" and start parenthesized reference with
@pxref.
Thanks for checking that. I had it wrong and I learned something!
System can no longer be reconfigured
Hi, I can no longer reconfigure a system with any of these methods: 1. "guix deploy" which I use almost exclusively 2. "guix system reconfigure" after a recent pull 3. "./pre-inst-env guix system reconfigure" with a recent Git checkout. Guix hangs during the system activation step. Any ideas? Kind regards Felix
File name component is not a directory "/var/run/dbus"
Hi,
Guix compiled from Git (and with very minor modification) cannot
activate a system because /var/run/dbus is not a directory. The error
message is below.
On mine, the folder is a symbolic link to /run/dbus. Any ideas?
Did something change recently there?
Kind regards
Felix
* * *
switched from generation 463 to 463
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
making '/var/guix/profiles/system-463-link' the current system...
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/rnng9ihdvrf9q0b1617n4yv0nf69h40b-etc...
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
WARNING: (guile-user): imported module (guix build utils) overrides core
binding `delete'
Backtrace:
In ice-9/eval.scm:
619:8 19 (_ #(#(#)))
In guix/ui.scm:
2326:7 18 (run-guix . _)
2289:10 17 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
859:3 15 (_)
839:4 14 (call-with-status-report _ _)
In ice-9/boot-9.scm:
1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
661:37 12 (thunk)
In ice-9/boot-9.scm:
1747:15 11 (with-exception-handler # …)
In unknown file:
10 (primitive-load "/var/guix/profiles/system-463-link/act…")
In ice-9/boot-9.scm:
260:13 9 (for-each # _)
In unknown file:
8 (primitive-load "/gnu/store/1x975c8prbmb09gaymr583bgy7b…")
In ice-9/eval.scm:
619:8 7 (_ #f)
In gnu/build/activation.scm:
103:2 6 (mkdir-p/perms "/var/run/dbus" #("messagebus" "x" 988 …) …)
In ice-9/boot-9.scm:
1747:15 5 (with-exception-handler # …)
1747:15 4 (with-exception-handler # …)
1747:15 3 (with-exception-handler # …)
In gnu/build/activation.scm:
78:6 2 (_)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
file name component is not a directory "/var/run/dbus"
Re: Adding plumbing subcommand 'derivation'?
Correction: On 18/04/2024 13:57, Christina O'Donnell wrote: [...] `guix store get-references` `guix store get-referrers` `guix store info` - dumps the `path-info` `guix store put xyz` - puts xyz into the store as a fixed derivation binary blob. [...] I've just checked and get-references and get-referrers are available as: `guix gc --references` `guix gc --referrers` Kind regards, Christina
Re: Adding plumbing subcommand 'derivation'?
Hi, In the interest of throwing ideas out there, and with the caveat that this is rather uninformed: I think having a derivation sub-command makes the most sense to me. E.g. `guix derivation show` for `guix drv-show` `guix derivation update` for `guix drv-drv` (or 'refresh' or 'fix') I have also been thinking that it'd potentially be useful to have something like: `guix derivation edit /gnu/store/...-xyz.drv` Which then produces a temp directory that you may edit with whatever tools you like, then on command checks for changed files, recompute hashes recursively, and puts the modified derivations and back into the store. I think this would be mainly be useful as a debugging tool or for changes that no longer build, for cases where the new `guix derivation update` wouldn't work. On the tangential subject of plumbing commands, I've also started to write a `guix store` command that simply exposes functions in (guix store) as a command line interface as a way of learning the internals of Guix. This would have sub-commands like: `guix store get-references` `guix store get-referrers` `guix store info` - dumps the `path-info` `guix store put xyz` - puts xyz into the store as a fixed derivation binary blob. I say this as a way of clarifying the design of `guix derivation`, not as extra stuff that needs go in at the same time. Most of these commands might be deemed unnecessary. Alternatively, as you say, Ricardo: `guix inspect get-references` `guix inspect get referrers` `guix inspect path-info` `guix inspect show-derivation` However, in that case, another home would need to be found for drv-drv at minimum since I wouldn't expect 'inspect' to modify anything. Kind regards, Christina On 18/04/2024 09:40, Ricardo Wurmus wrote: Hi Simon, So I propose to add the plumbing command ’derivation’. Any objection? I think it's useful to have. To avoid proliferation of sub-commands, do you think we could put this under "inspect", a generic sub-command for all sorts of as yet to be invented introspection tools?
Re: [shepherd] several patches that i deem ready
hi Ludo, > > i have prepared the rest of my commits that were needed to hunt down the > > shepherd hanging bug. you can find them at: > > > > https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila > > > > there's some dependency among the commits, so sending them to debbugs would > > be either as one big series of commits, or a hopeless labirinth of patches > > otherwise. > > > Yes, but OTOH, piecemeal, focused changes sent to Debbugs are easier to > review for me. (There are 34 commits in this branch touching different > aspects.) i understand that, but cutting out some of the commits from this branch is a lot of work at best, and not possible at worst due to semantic dependencies. e.g. how shall i implement proper error handling without being able to inspect what's happening (i.e. proper logging)? nevertheless, i'll rebase my work on the devel branch eventually. it will be a lot of pain in itself, but if i need to reimplement/rebase stuff by hand anyway, then i'll try to further sort the commits in a least-controversial order. > I cherry-picked a couple of patches. > > Some notes: > > + 94c1143 shepherd: Add tests/startup-error.sh > > Redundant with ‘tests/startup-failure.sh’ I think? one of them just returns #f from its start lambda, while the new one throws an error. they exercise different code paths in shepherd. > + e802761 service: Add custom printer for records. > > > Good idea, but the goal is to remove GOOPS, so put aside for now. ok, i'll get rid of it (move it away into a local kludge branch). its main purpose is to be able to simply FORMAT some service objects into the log. > + af2ebec service: respawn-limit: make #f mean no limit. > > I’d rather not do that: one can use +inf.0 when needed. i found the respawn-limit API somewhat confusing (it requires a cons cell with two numbers). i thought #f could be a simple way to disable the respawn limit; simple both in implementation and as an API. FWIW, it's the first time i've ever met +inf.0 but as you wish, we can manage without this commit. > + 095e930 shepherd: Do not respawn disabled services. > > That’s already the case (see commit > 7c88d67076a0bb1d9014b3bc23ed9c68f1c702ab; maybe we hacked it > independently in parallel). err, hrm... i'm not sure anymore why i created that commit. "Respawning ~a." is printed before calling START-SERVICE (that then does honor the ENABLED? flag). maybe i recorded this commit without actually checking whether the service is respawned (as opposed to merely printing an inert log message). i'll get rid of this, but the incorrect respawning message will remain a source of confusion. > + dbc9150 shepherd: Increase the time range for the default respawn limit. > > This arbitrary and thus debatable, but I think the current setting > works well, doesn’t it? the current limit will not catch services whose start-to-fail time is not in the ballpark of 1 sec (5 times in 7 seconds). the startup-to-fail time of the service i'm working with is way above 1 sec. > + e03b958 support: Add logging operators. > + 39c2e14 shepherd: add call-with-error-handling > > I like the idea: we really need those backtraces to be logged! > There are mostly-stylistic issues that would need to be discussed > though. I’d like logging to be less baroque; I’m not convinced by: what do you mean by 'baroque' here? too verbose in the source code? > + 7183c9c shepherd: Populate the code with some log lines. > > This is exactly what I’d like to avoid—adding logging statements all > around the code base, possibly redundant with existing logging > statements that target users. > > What I do want though is to have “first-class logs”, pretty much like > what we see with ‘herd log’ etc. To me, that is much more useful than > writing the arguments passed each and every ‘fork+exec-command’ call. don't they serve two entirely different purposes? 1) logs meant for the users of shepherd (aka herd log) vs 2) logs that the shepherd and service developers need to understand shepherd's temporal behavior. i added every logging related code in the various pursuits of hunting down specific bugs. 1. bug gets triggered 2. stare at logs, have some questions 3. add some more log statements 4. goto 1. i'm not aware of any way to efficiently inspect the temporal behavior of a codebase other than adding explicit log statements. ideally using multiple, hierarchical log categories that can be turned on and off separately, both at runtime and at compile time. what i added to shepherd is a super simplified, local, mock version of that (short of porting/finding a proper logging library in scheme). > I’ll have to look further that branch. I admit I have limited bandwidth > available and, perhaps selfishly, I like to use my free-time computing > to hack myself. it is of course your call how you make a tradeoff between building/fixing things by yourself, and spending your time
Re: Should we include nss-certs out of the box?
Hi, Here's my attempt at adding 'nss-certs' to '%default-packages'. https://lists.gnu.org/archive/html/guix-patches/2024-04/msg01187.html I've removed the 'nss-certs' entry from the installer, as suggested by Ludo, and I've updated the docs, hopefully all the relevant parts. Can you think of anything else that may need to be updated? Thanks, best wishes, Fabio. -- Fabio Natali https://fabionatali.com
No public interface for shepherd-package (Was: Shepherd service logging)
Hi Attila, On Tue, Dec 05 2023, Attila Lendvai wrote: > AFAIU that will lead to quite some local recompiling that are not necessary. > you can just set the shepherd package of the shepherd-root-service-type to a > custom package. > > e.g. this will use the latest shepherd from the shepherd channel: > > (operating-system > ... > (essential-services >(modify-services (operating-system-default-essential-services > this-operating-system) > (shepherd-root-service-type > config => > (shepherd-configuration >(inherit config) >(shepherd (@ (shepherd-package) shepherd))) I have been using that code to get access to the timers in the Shepherd's development branch. Unfortunately, one of my servers can no longer be reconfigured via 'deploy' or 'system reconfigure'. Following podiki's and jab's kind advice on IRC yesterday, I recompiled Guix locally. I also provided all channels locally via -L. That 'system reconfigure' failed too, however. The error message was: Module named (shepherd-package) has no public interface. Is your way of using the latest Shepherd version still recommended, or should I be doing that differently now? Thanks! Kind regards Felix
Re: Adding plumbing subcommand 'derivation'?
Hi Simon, > So I propose to add the plumbing command ’derivation’. Any objection? I think it's useful to have. To avoid proliferation of sub-commands, do you think we could put this under "inspect", a generic sub-command for all sorts of as yet to be invented introspection tools? -- Ricardo
