bug#44808: Default to allowing password authentication on leaves users vulnerable
Hi guix users, It strikes me that a better course of action here would be, rather than providing a warning that might not be noticed by the user, to remove the default and force people to explicitly put `password-authentication? #t` or `password-authentication? #f`. That way if I have set up a headless server (possibly having a temporary keyboard/mouse/monitor during initial install, then forever logging in afterwards over intranet using my super secret password "raid5isnotagooddog"), with an existing `configuration.scm` that does not explicitly give the setting, I cannot accidentally lose access to my headless server by doing a random `guix pull && sudo guix system reconfigure configuration.scm` without noticing the warning. Especially since there exists an `unattended-upgrades-service-type` which automates this `guix pull && sudo guix system reconfigure configuration.scm`, which makes changing this default ***VERY DANGEROUS*** in this use-case. I'd rather I noticeably error out in this case. Then later after a year give a "sane" default, after people who have depended on the existing `password-authentication? #t` have already explicitly put the setting in their `configuration.scm`. Thanks raid5atemyhomework
bug#46398: hedgewars 1.0.0 fails to build again
"bdju" writes: > Apparently there were issues back in August. Version number is still > 1.0.0. Current build has been failing a couple weeks maybe. > Build log here: http://ix.io/2OPc > guix version: guix (GNU Guix) b421b2f66ec5b39bd1331e276bff5f9698cd65dc > I am using Guix System. Hello, thanks for the report. Fixed in commit c7296465cff593bd3c82c7152e09f4337252ce4d.
bug#46394: ISO image installer test fails
On Mon, Feb 08, 2021 at 11:04:48PM -0500, Leo Famulari wrote: > On Sun, Feb 07, 2021 at 02:47:30PM -0500, guix-comm...@gnu.org wrote: > > commit 589b6be99634d0c42cf25e1599b2f62b0d8e89f7 > > Author: Efraim Flashner > > AuthorDate: Sun Feb 7 21:47:01 2021 +0200 > > > > gnu: xorriso: Update to 1.5.4.pl02. > > > > * gnu/packages/cdrom.scm (xorriso): Update to 1.5.4.pl02. > > I think this update broke the system test 'iso-image-installer'. I did more tests to confirm the problem, and reverted the commit with 8f8a1485b80de707caecf6e7e29b520cd8cf611e
bug#46385: User awareness of Anti-Features
On Mon, Feb 08, 2021 at 01:28:40PM +, soheil--- via Bug reports for GNU Guix wrote: > Users should be aware of anti-feature of packages. > It is best to have anti-feature tag in anti-feature packages so that user > know which program has anti-features; Like F-Droid. Also, user should be > aware of anti-feature during installation. And wherever this awareness is > needed... I use F-Droid, but I dislike their "anti-feature" messaging. It's not clear to me that it's an example we should follow.
bug#46385: User awareness of Anti-Features
Hi, On Mon, 2021-02-08 at 13:28 +, soheil--- via Bug reports for GNU Guix wrote: > Users should be aware of anti-feature of packages. > It is best to have anti-feature tag in anti-feature packages so that user know > which program has anti-features; Like F-Droid. Also, user should be aware of > anti-feature during installation. And wherever this awareness is needed... > > An example is Telegram, Telegram is a program that user connects to a > proprietary server, and users who know less about computer softwares, > are not aware of the anti-feature. I'll have to think some more on whether this is something Guix needs, but I do have a partial concrete implementation proposal: Packages can have a ‘properties’ field, e.g. from gnu/packages/bioconductors.scm: (define-public r-reactome-db (package (name "r-reactome-db") (version "1.70.0") [...] (properties `((upstream-name . "reactome.db") Maybe add a ‘anti-features’ entry field for some packages? E.g., (define-public some-twitter-app (package (name "tweet") [...] (properties `((anti-features x y z) x, y and z can be symbols, e.g. based upon from https://f-droid.org/en/docs/Anti-Features/ * ads (I don't think any application in Guix has these?) * tracking (should be patched out if possible) * non-free-network-services * non-free-dependencies (probably not allowed in upstream Guix, but maybe in a channel) The code behind ‘guix show’ and ‘guix search’ would need to be adjusted to display anti-features, and the ‘guix install’ code should warn if someone installs a package with anti-features. Greetings, Maxime signature.asc Description: This is a digitally signed message part
bug#38929: sane-hpaio not found by simple-scan?
I have a USB-connected HP DeskJet Ink Advantage 1515 printer/scanner. On my own system (this is a full Guix System, not Guix on a foreign distro) I modified the configuration.scm: ```scheme (use-package-modules #;... scanner) (operating-system #;... (services (append #;... (modify-services %desktop-services (sane-service-type _ => sane-backends #;...) ``` After `sudo guix system reconfigure configuration.scm`, `simple-scan` still could not find it. However, on reboot, it was able to find my already-connected USB printer/scanner without any issues. Perhaps only some kind of force-trigger of `udev` would be needed after the above setup, but `udev` is pretty early in the Shepherd tree. On the other hand the `sane-service-type` documentation in `info guix` is ***severely*** lacking, and the documentation is somehow lost in the middle of documentation about geolocation services, so it should probably be fixed. Thanks raid5atemyhomework
bug#46402: Cuirass rebuilds the same packae multiple times
Hey Ludo, Thanks for sharing your thoughts, it's always useful :). > Seems to me that ‘BuildSteps’ is an orthogonal concern that has little > to do with Cuirass’ job and with its data model. In Hydra I saw that as > a (necessary) kludge. I'm not sure to follow you here. Cuirass and Hydra have an almost identical database schema and are now working very similarly from what I understand. In Hydra, a JobSet (Specification in Cuirass) has several Builds. Each Build can be broken in several BuildSteps, corresponding to transitive derivation inputs that must be built. Hydra manages to get those BuildSteps to be built in a topological order, in the same way as the Guix Build Coordinator. This makes me think that we could implement this exact same mechanism in Cuirass but I'm maybe missing something. > If Cuirass would instead delegate derivation build requests to a > Coordinator/daemon-like thing, it wouldn’t have to worry about those > details. That would better separate concerns. I think that having Cuirass delegating its builds to the Coordinator is not the right move. That would mean doubling the size of the CI code base, doubling the number of databases, for a feature that we could implement in Cuirass, just by making it catch-up on Hydra. Thanks, Mathieu
bug#46402: Cuirass rebuilds the same packae multiple times
Hi, Mathieu Othacehe skribis: >> here is an example: https://ci.guix.gnu.org/build/287478/details and >> https://ci.guix.gnu.org/build/287476/details are being built at the >> same time, and the logs currently show they are both running the test >> phase of the php package. > > Thanks for the report. This problem has been briefly discussed > yesterday. It has been introduced by the new remote building mechanism > in Cuirass. Hydra solves it by breaking each build into buildsteps > corresponding to the derivation inputs. > > The buildsteps are then submitted to the workers in a logical order. I > proposed to introduce a similar mechanism in Cuirass but Ludo expressed > doubts. Ludo do you think this problem could be solved otherwise? I’m not sure exactly but I can share my feelings. :-) Seems to me that ‘BuildSteps’ is an orthogonal concern that has little to do with Cuirass’ job and with its data model. In Hydra I saw that as a (necessary) kludge. I like the way the Coordinator does it, and AIUI it’s pretty much the same as what the daemon is doing: submit build requests in topological order, such that when a derivation build is submitted, its prerequisites are known to be built already. I suppose what makes it more difficult here is that we have this extra “job” abstraction on top of derivations; everything in Cuirass revolves around jobs, which leads to this impedance mismatch. If Cuirass would instead delegate derivation build requests to a Coordinator/daemon-like thing, it wouldn’t have to worry about those details. That would better separate concerns. This is quite a hand-wavy reply but I hope it’s useful! Thanks, Ludo’.
bug#46385: User awareness of Anti-Features
Users should be aware of anti-feature of packages. It is best to have anti-feature tag in anti-feature packages so that user know which program has anti-features; Like F-Droid. Also, user should be aware of anti-feature during installation. And wherever this awareness is needed... An example is Telegram, Telegram is a program that user connects to a proprietary server, and users who know less about computer softwares, are not aware of the anti-feature.
bug#46292: more info
Hi, This is not due to NFS, but due to the fact that the NFS mount is mounted nosuid (and nodev, probably). I can reproduce it on a local filesystem mounted nosuid. It seems that, when remounting a bind mount which is originally nosuid inside a mount ns, you need to specify explicitely the nosuid option, or else can_change_locked_flags()[1] will return false. [1] https://github.com/torvalds/linux/blame/master/fs/namespace.c#L2480 There's a concept of "locked mount flags" that cannot be cleared by a less privileged user (see [2]). Our call to 'mount -o remount' ignores the fact that the filesystem is mounted nosuid (and does not include this flag), so the remount call tries to remove nosuid, and fails. [2] https://github.com/torvalds/linux/commit/9566d6742852c527bf5af38af5cbb878dad75705 This probably needs to be fixed in Guix by fetching the current mount flags and including them in the bind+remount+readonly call. Unfortunately I did not find an easy way to convert mount flags in /proc/$$/mountinfo to flags for the mount syscall... Lucas
