IRC channel logs


back to list of logs

<BlackMug>namecoin is nice project to be considered used by guix but that different discussion
<BlackMug>lets see, i opened already 7 tickets in the bug section
<BlackMug>i hope i wont be kicked because of annoying hehe
<raingloom>uuugh. i'd rather Guix not get involved in cryptocurrencies. the planet doesn't need that. but that's a rather off topic discussion.
<BlackMug>actually by name it looks like cryptcurrency but it isnt
<raingloom>off topic: leoprikler thanks for packaging renpy :D i was just reading the patches coz i'll be helping a kid learn python with it so i thought i'd better familiarize myself with it.
<BlackMug>it uses blockchains to solve the clearnet DNS safety issues
<pkill9>blockchains are the problem though, although apparently there are non-proof-of-work based ones
<leoprikler>Learning programming with visual novels, now that's some education I can get behind.
<BlackMug>read about it:
<pkill9>linux is pretty secure though
<pkill9>i just don't want to believe it isn't lol
<pkill9>what can run on sel4?
<BlackMug>pkill9 ,
<raingloom>pkill9: afaik it can be used as a hypervisor and run linux. so it can be a safer way to separate linux VMs.
<BlackMug>pkill9 sel4 is microkernel , and microkernel by how it operates safer than monolithic kernels
<raingloom>i wonder if Minix could work tho. it has some interesting ideas regarding resilience. like, your GPU driver can just crash and get restarted without pulling the whole kernel with it.
<zzappie>BlackMug: there is also, many guixers may know them
<raingloom>it can already run the userland of one of the BSDs. (Net? Open?)
<raingloom>well, some of the userland. probably not everything.
<raingloom>(re DNS stuff: i'd rather have a petname system than global consensus.)
<BlackMug>zzappie true but i dont know if it provides the same security,features as namecoin
<BlackMug>raingloom clearnet DNS is absolutely disaster so as TLS (needs alot of configurations, some by design cant do anything about)
<BlackMug>I communicated more than one time through email with server maintainer to hardenize its TLS,DNS,CSP... but no respond i received
<raingloom>for petnames and security stuff see:
<raingloom>its author might actually be lurking here right now, they're a guixer as well :D
<raingloom>and the NDN papers
<pkill9>so basically the dream of the FOSS desktop is dead because it's not secure, gg
<BlackMug>pkill9 yeah sadly it isnt secure as it should be
<BlackMug>raingloom these projects not for anonymity just decentralization
<raingloom>BlackMug: did you read the ANDANA paper? :)
<pkill9>is desktop linux even salveagable?
<BlackMug>raingloom i only saw their main website
<raingloom>it's linked there. read it. :3
<raingloom>pkill9: lots of people are hyped for GNOME 40. there is certainly interest in desktop Linux.
<pkill9>yea but it's all insecure, so, meh
<raingloom>well, not necessarily. AppImage &co have sandboxing. the problem is that not every distro uses sandboxing.
<lfam>It's hardly worse than other general-purpose desktop OS
<BlackMug>pkill9 i doubt that it will be fixable on a short time, maybe later or maybe not
<raingloom>that's why I like Chris Webber's proposition that Guix should adopt an OCAP model.
<pkill9>the linked article suggests using bubblewrap with apparmor
<pkill9>yea if all of them suck in terms of security then it's all good ,lol
<lfam>Well, it's like, what is security for?
<lfam>Everyone gets their work done and the world keeps on turning
<raingloom>lfam: if you are an activist, your computer will be targeted by some nasty people.
<lfam>A lot of us make efforts to improve the security of the system, but it's not clear that things are so bad that we should stop using computers
<lfam>Yeah, and that's why activists / dissidents are advised against using desktops
<lfam>But it's a bit of an edge case
<lfam>If computing was really so insecure, then international trade and finance would collapse
<lfam>Bitcoin would be impossible
<BlackMug>raingloom where did you read NDN is for anonymous purposes? it just fixes stuff which is effect IP like spoofing but didnt talk about anonymizing the traffic.
<raingloom>not necessarily. it's only an edge case if you're lucky enough to live in certain countries.
<lfam>Bitcoin is a great example. It's basically a walking bug bounty.
<lfam>I'm not sure we disagree raingloom
<pkill9>hmm true
<lfam>And, if you are some kind of activist targeted by a government, they are going to hurt you whether or not they can break into your computer
<BlackMug>lfam what you said true, but for e.g Windows/Mac have more security than GNU distros, GNU distros are free and less likely to be maliciously by default but less secure
<raingloom>sure, but you shouldn't make it easy for them. and if they can spy on your communications, you have no chance to organize anything large.
<lfam>If computer security is so bad, why hasn't Coinbase lost all its money yet?
<lfam>Well yeah, that's why I help improve security here, raingloom
<pkill9>it's sad that windows is more secure
<BlackMug>so yeah one will choose what he will trade for what
<lfam>In terms of organizing, I'm not sure that surreptitious organizing is really the crux of the matter. At least in the USA, the last year saw several major uprisings, all of which were organized in public
<lfam>Or, they were not organized at all, but just spontaneously erupted
<lfam>And when some people tried to use secret messaging channels, their enemies just lied about who they were and joined the channels
<lfam>Now, it's definitely different than, like, Myanmar
<lfam>I just think that the state of computing is both terrible and good enough :)
<BlackMug>raingloom still theoritic/research project same GNUnet
<leoprikler>in which way is windows more secure?
<pkill9>i still prefer using linux to windows
<pkill9>well, more specifically ,guix
<raingloom>BlackMug: not really, NDN has way more researchers behind it from what I can tell. you don't see GNUnet at military communications conferences.
<pkill9>what's NDN/?
<pkill9>that article recommmends not using firejail
<BlackMug>leoprikler many exploit mitigation
<raingloom>tbh Linux (in theory) has all the elements it needs to be properly secure, ie. to run everything with the fewest necessary priveleges. but applications and distros don't seem to use that. at least not on desktop.
<BlackMug>preferable to read:
<raingloom>btw i know like half of us hate webshit (i do too) but consider, Linux userspace running on WASM running on Linux
<raingloom>like in the Birth and Death of JavaScript
<BlackMug>if you want to read why Windows is not preferable to be used due to its malicious powers read:
<lfam>So, what would be next steps for Guix?
<raingloom>imho we should make services run with minimum privileges.
<BlackMug>lfam using MAC for every package as mandatory action
<lfam>And, what would that entail?
<BlackMug>raingloom yeah exactly that can be achieved with MAC
<BlackMug>lfam lowering the impact of malicious/untrusted packages
<lfam>I mean, concretely, what tasks would we need to carry out?
<raingloom>i think NixOS already has some hardening stuff. we should steal those.
<leoprikler>I don't really trust the "sandboxing = security" crowd, especially since most sandboxes have at some point been shown to connect to the Earth's mantle.
<raingloom>lfam: i'd consult with Chris, they clearly have thought a lot about this stuff and could help with the finer details
<lfam>Chris Webber?
<BlackMug>lfam i dont understand your question about what tasks, whatever task needed to improve exploit mitigation within the distro
<raingloom>unless they're too busy with Spritely right now
<lfam>BlackMug: You said we should be "using MAC for every package as mandatory action". I was asking, how do we do that?
<lfam>What's the first step?
<pkill9>it also mitigates damage caused by buggy packages
<OriansJ`>there is no protection when a user installs a malicious/untrusted package
<pkill9>that might delete your data
<BlackMug>leoprikler sandboxing through docker is horrible no question, but we are talking about MAC like apparmor/selinux
<OriansJ`>there is nothing that could be done with that level of behavior outside of training.
<OriansJ`>SELINUX/AppArmor does nothing when a user created binary acts on user created files
<pkill9>it's almost impossible to know what is trusted/malicious though
<pkill9>no one reads every line of code, tracks every commit
<OriansJ`>pkill9: except crazies
<raingloom>pkill9: doing so should not be necessary for security
<OriansJ`>or trivial projects like stage0
<pkill9>yea raingloom
<OriansJ`>raingloom: wrong
<raingloom>imho first step would be to run guix-daemon in a way that it cannot access more than it needs to
<BlackMug>lfam enable MAC by default and make package maintainers define their apparmor profile by force (selinux depend on which one going to be implemented)
<lfam>Okay, could it be done incrementally? Remember, there are more than 16000 packagse
<lfam>Also, Guix doesn't have a model where there are "package maintainers"
<lfam>It's more of a collective effort
<pkill9>BlackMug: that's what I want to do
<pkill9>how I want guix to be set up, with apparmor
<BlackMug>lfam ok then package uploaders or whatever you wanna call them
<pkill9>and package definitions having an apparmor profile
<BlackMug>and can be incrementally why not
<lfam>I guess it could be something we recommend for a while
<OriansJ`>now who is actually going to do *ALL* of that work?
<lfam>Guix packages aren't "owned" by maintainers or uploaders
<lfam>Like, I said, it's a collective effort
<lfam>I think that BlackMug volunteered :)
<raingloom>OriansJ`: even if you read it, you won't notice all bugs / vulns. Chris's latest talk on Spritely quotes a good study, where they showed some vulnerable code to security pros and no one could find all the holes that were inserted.
<lfam>It all sounds a bit pie in the sky, to be honest
<lfam>"Just force people to do this thing 16000 times"
<OriansJ`>raingloom: there are only two types of programs: So simple there are obviously no bugs and so complex there are no obvious bugs
<BlackMug>OriansJ` anyone who want his package to be included in guix packages should define the apparmor profile for it , without profile no package upload/included to the main repo
<raingloom>see talk
<pkill9>this is why i'd prefer a basic default profile for all applications
<lfam>Right, so it would be a required thing for new packages
<pkill9>where they only have access to their own data
<raingloom>OriansJ`: I, too, like Plan 9. :D but i also know why simplicity isn't always best.
<DanklyTuned>with all this talk of goblins i sure do hope to hear reference to Goblin Slayer at some point
<BlackMug>lfam yes exactly mandatory thing
<leoprikler>lfam: tbf 15000, because 1000 of them are Emacs packages, that would inherit their policy from emacs
<lfam>As someone who's been around for a while, I'm pretty sure it's not gonna happen
<OriansJ`>BlackMug: so you are going to need to create training material and help people learn how to do it correctly
<lfam>Not like that anyways
<leoprikler>or at least I'm not aware of any special policy bindings in elisp
<BlackMug>OriansJ` no whether they learn that by themselves or goodbye
<OriansJ`>raingloom: I'm a bootstrapper here so simplicity is all I really know these days ^_^
<lfam>Maybe if we can copy these profiles from somewhere else
<pkill9>why not just focused on a single default profile then
<raingloom>lfam: i don't think it's feasible to do it for every package, but we should certainly do it for shepherd services.
<lfam>It's been discussed in that context before, too
<OriansJ`>BlackMug: security without help doing it right ensures that it isn't done right.
<lfam>Or at least, other approaches to restricting the services
<DanklyTuned>I've seen here and there some light discussion of Whonix using Guix.
<BlackMug>pkill9 can causes alot of troubles as each package need its own defined privileges,paths...etc
<DanklyTuned>Whonix potentially*
<BlackMug>OriansJ` apparmor or MAC in general not secret thing its online and documented already
<OriansJ`>BlackMug: correct and most programmers do the following rule: Allow everything
<BlackMug>DanklyTuned there is no usage of guix in whonix, but whonix is the distro i know care about security at the moment + qubes
<BlackMug>OriansJ` yeah then goodbye to his package, wont be included thank you
<DanklyTuned>Yeah, the discussion I saw was about potential future usage of Guix, BlackMug
<OriansJ`>BlackMug: And once you eject the majority of developers, who is going to update security patches?
<BlackMug>DanklyTuned true, i wish guix do things better than other known gnu/linux towards security
<raingloom>tbh this whole discussion could just lead to security LARPing. this is not something that can be meaningfully resolved on IRC, or with linking to random blog posts.
<OriansJ`>security in a community like this isn't a business where you are paying people to build things to spec.
<OriansJ`>You need to encourage people to do the right thing and make it easy for them to do it
<BlackMug>OriansJ` developers or package maintainer/uploader? there is different , we are not talking about devs of the distro
<lfam>It's all the same in Guix
<BlackMug>raingloom true, should considered within the main devs of the distro
<DanklyTuned>(Note, I'm not aware of the surrounding security discussion, I just saw the word whonix and thought I'd mention Guix being discussed by some whonix peeps)
<lfam>Anyways, I agree with OriansJ`. "My way or the highway" is not what Guix is going to do regarding this matter
<OriansJ`>BlackMug: I agree in the need for security improvements in Guix but the methods required are more making it easier to do the right thing and giving people help
<pkill9>I agree with OriansJ`
<OriansJ`>which means someone is going to have to do that work BlackMug
<lfam>There are a lot of research projects that focus on security above all else, but Guix serves a variety of use cases
<BlackMug>OriansJ` yeah encouraging them by go and read how to do things right , things doesnt come with golden spoon
<OriansJ`>BlackMug: Who does, decides. If you aren't willing to do the work required; don't expect anyone here to make you happy.
<BlackMug>OriansJ` why one or two doing profiles of x,y,z packages ? i dont understand this method and the package developer doesnt do a thing about? this bad development on the long run
<OriansJ`>I wanted guix to be bootstrapped from a hex assembler and spent 5 years doing the work required with a few other people and now we have it.
<BlackMug>OriansJ` for me i would do the work to make MAC work properly within Guix not making profiles for the packages
<OriansJ`>BlackMug: you either need to do the work to get the feature/improvement into guix or hope someone else is willing to do the work for you.
<BlackMug>feature is not the issue we are talking here, once guix has the ability to support running MAC this is done
<DanklyTuned>Anyone here run a Mastodon or Pleroma instance from a Guix server? Or know of anyone mentioning having done so? I'm intending to do so over the next couple days so was just curious
<OriansJ`>BlackMug: that is fine if that is all you are willing to help improve guix but please understand the rest of the remaining work needs someone to do it too.
<pkill9>in that case it just needs apparmor userland tools packages
<BlackMug>but to give profiles for 1000s package thats hell of a no and there will never a secure packages within guix if its not done by the packages devs themselves
<pkill9>i don't think you realise how few package maintainers there are
<OriansJ`>BlackMug: how many devs do you think Guix has building package definitions?
<BlackMug>i dont know
<DanklyTuned>What are your proposing to be done, BlackMug?
<lfam>We have about 200 people working on Guix
<lfam>And about 50 people who work on it a lot
<OriansJ`>BlackMug: So even 1 guix dev put on that task is 2% of all possible development effort.
<BlackMug>ok good, package by package on the long run by each of these devs (not only 2 or 1 working on this task) will be then having each app its own profile
<lfam>I have to go. Good luck!
<BlackMug>lfam tyt, thank you <f>
<OriansJ`>BlackMug: well we can provide a template profile for all of the packages real quick: allow everything and then allow someone to slowly improve the security profiles for each packages.
<BlackMug>can be why not
<BlackMug> similar to this maybe
<BlackMug>(still experimental)
<OriansJ`>Now if one wants the security profiles to be "good", it would be best if a person or so was willing to dedicate themselves to the task until they feel it is sufficiently addressed.
<OriansJ`>there might be profiles that can be copied from other distros with only minor tweaks
<raingloom>(what i'd like to see for non-service packages is a way to say that "this app can access these files, but ask me before it tries to rm -rf $HOME")
<OriansJ`>but such work needs to be done by someone who is familiar with the best practices and how to implement such things correctly.
*raingloom staring at Steam with accusing eyes
<BlackMug>OriansJ` correct like debian or so from the major distros
<OriansJ`>BlackMug: but that is still work for someone to put in who cares about having it done right.
<OriansJ`>might be far less work than writing everything from scratch but still needs some human touch to get it right
<BlackMug>OriansJ` i actually wanted guix and whonix to set and talk as they may reach to something for the future since they both care about security and doing things right
<BlackMug>but i failed to reach or to whom i should talk to from guix side
<pkill9>talk to rekado or civodul
<pkill9>actually idk
<BlackMug>(i know whonix side because im contributor to it)
<OriansJ`>civodul is usually a good starting person with guix and then there are people who specialize in things which you might care more about.
<OriansJ`>for example janneke and me tend to be the people who know the most about the bootstrapping work.
<BlackMug>i sent civodul a message, no respond until now because hes busy maybe with other stuff or so (i cant know)
<BlackMug>so if there is one or more than one willing to have meeting chat lets go why not, but it depends as well on what guix devs interested to do at the moment maybe they dont want to focus on security now and so on
<apteryx>BlackMug: it may be best to send it to guix-devel to broadcast it to a wider audience
<BlackMug>i dont have problem if its the right path to take
<BlackMug>but i need to see interest first from guix devs to work with other projects like whonix to do stuff on guix, if everything fine lets do it.
<pkill9>BlackMug: I'm interested in this, I'm not an expert or anything in this stuff though
<BlackMug>me 2 im interested but without main devs sitting like man to man talk nothing can be achieved
<BlackMug>anyway lets see how this goes if there is a willing from guix devs to go further on this, g2g now
<BlackMug>take care, god bless
<genr8_>woops. shut my main system down somehow
<genr8_>also wrong channel...
<malik>I am making a custom package/service(?) (with define-public) of a pom.xml maven based project. It'
<malik>s failing on a depnecy I see on maven though :(
<malik> more details i dont know where to look past here
***iyzsong-- is now known as iyzsong-w
<lfam>I'm testing the update of Calibre
<lfam>Calibre is working, but the patches break QGIS: <>
<lfam>I'm working from this branch:
<lfam>I wonder if anyone has any ideas?
<lafrenierejm>Does anyone have a working HiDPI i3wm setup they'd be willing to share? It's unclear to me how to get my user-local Xresources read when logging in via a display manager.
***phossil is now known as tophullyte
<i1l[m]>lafrenierejm, if thee going desperate: Sway has a "scaling" setting.
<i1l[m]>it is a i3 clone afair.
***i1l[m] is now known as i1l
<civodul>Hello Guix!
<tissevert>Hi Guix
<bonz060>Hi tissevert
<bonz060>Could someone review: Also, why does it show a red? I see it fails when applying a patch :(
<cbaines>bonz060, it looks like you've added packages (at least python-roman) to the bottom of a module, which increases the chance of there being a merge conflict, so it could just be that
<leoprikler>raghavgururajan: do you think your gstreamer stuff could make it to staging instead of c-u?
<tissevert>hmmm looks like vim-full is broken again : (
<tissevert>beyond my vain hope to be able to fix such one day, is there something like a «stable» channel ?
<leoprikler>There is no stable channel, you would have to roll one yourself
<leoprikler>(though currently staging seems rather stable, ironically)
<tissevert>is that a specific channel ?
<tissevert>how would I go about rolling my own stable channel ? forking guix.git from savannah and adding commits one by one checking everything I use still builds ?
<leoprikler>staging is a savannah branch, which houses commits, that cause a moderate amount of rebuilds
<leoprikler>and yes, you'd cherry-pick guix commits all day in your guix fork
<tissevert>it's a branch ? is the default «master» ? cause that's what I have in /run/current-system/channels.scm but I never attempted to change it
<leoprikler>the default branch is master and it's not recommended to use staging or core-updates instead
<leoprikler>they rarely receive the security updates, that go on master
<tissevert>oh, thank you
<tissevert>but somehow you say they are more stable than master ? how come ?
<tissevert>aren't packages built before going to master ? could the build fail because of a misconfiguration on my system ? it seems to be the CheckCopyPaste test of vim-full that fails
<leoprikler>by "more stable" i simply mean it hasn't received any updates for two weeks
<tissevert>ohh ^^ so not the breaking change, I see
<cbaines>are you sure vim-full is broken? I can see substitutes for /gnu/store/5al5fs6z2sjhm6524nbafygqpjmz0by1-vim-full-8.2.2689 at least
<cbaines>hmm, not from though, even though Cuirass claims to have built it
<cbaines>anyway, has a substitute
<tissevert>hmmm I mean I «guix system reconfigure»d, I have vim-full in my packages, and somehow the poor beast attempted to build it and failed a test
<tissevert>so that means if I was using your channel I would have received a binary package directly ?
<cbaines>just try building it again, maybe the build for the latest version is more flaky
<tissevert>hmmm I have /gnu/store/g9zfy2fhcgrq8prmlcckc3nccr73f0k6-vim-full-8.2.2689 for --prefix in the configure flags in the build log
<tissevert>so it means it's a slightly different version ?
<tissevert>(I performed a «guix pull» right before reconfiguring)
<cbaines>no, I just shared the output with grafts, I see the same output /gnu/store/g9zfy2fhcgrq8prmlcckc3nccr73f0k6-vim-full-8.2.2689
<tissevert>it's building it again
<tissevert>and from the same derivation /gnu/store/x0nwbvrli5rxgsi44y2xl36a46b9dlnj-vim-full-8.2.2689.drv
<tissevert>hmmm it's applying a lot of grafts on the rest of the system
<tissevert>could it have worked Oo
<tissevert>ok it has worked ^^'
<tissevert>what the duck ? how can a build from the same exact input fail or work ? it's in the tests, not the build, so I suppose it means the tests in vim-full are poorly written and subject to race conditions or have other time-related weaknesses ?
<leoprikler>something like that, not all packages in guix are fully reproducible, sadly
<tissevert>well of course, guix can't be expected to magically make packages perfect
<tissevert>thanks for all your help ! I'm glad it works now
<tissevert>even though I'm still a bit confused about substitutes and why there was none available although it «built on Cuirass» (and how could I have checked all of this instead of coming here to ask for help)
<leoprikler>guix caches substitute failures, so as to not spam CI
<i1l> . Emm.. which is the minimal RAM for using Gnu Guix the package manager? lfam, hi.
<i1l>I mean, is it possible to get in a situation where substitute is available, but the "consumer device" just cannot cope with the strength of our majestic PM.
<allana>Hi everyone. I am curious if anyone has any tips for me. On my guix system, I have a custom channel with a package that I want to move to guix. When I try to "./pre-inst-env guix lint my-package" it resolves to the package in my channel and not the package in the git checkout of guix. Any suggestions?
<leoprikler>perhaps you added it wrongly to guix? otherwise try using -L so that local packages are first
<i1l>allana --pure ?
<leoprikler>--pure only works for environments
<allana>I'm actually a little frustrated. The guix manual is quite clear on how to work on guix, and I have never been able to replicate the steps to create a package, for example. I do create packages in my own channel without issue. But when working on a git chekcout of guix, I'n usually flooded with a bunch of warnings about how every source file is newer than a compiled *.go file and then something fails or produces an error that is not
<allana>clear and not obviously related to my own edits
<leoprikler>guix environment guix -- make?
<rekado>./etc/committer.scm now also deals with package additions. Use with caution.
<i1l>leoprikler, i mean guix environment --pure guix; ./bootstrap ...; ./pre-inst-env
<i1l>whatever allana wants.
<leoprikler>oh, sure, depends how pure and container-y you want to be
<i1l>idk what else can cause the trouble from a side channel. maybe some forgotten envvar.
<allana>even without the sidechannel issue, I have never been able to effectively make changes to a git checkout of guix and actually test to see if anything builds using guix. Entering into a pure guix environment and using pre-inst-env hasn't been a working solution for me. I must be doing something wrong
<i1l>allana if thee run `./pre-inst-env guix build nano` after building the daemon inside the checkout? question is if that the package, or daemon glitches.
<i1l>also, is the .bashrc clean? maybe thee did defined some envvars in it. they belong to .bash_profile (right?)
<efraim>how can I add something to the default-skeletons without copying lots of code from gnu/system or gnu/services?
<allana>i1l: the manual says "If you are hacking on the daemon and its supporting code or if guix-daemon is not already running on your system, you can launch it straight from the build tree". your comment confuses me, because I am under the impression that I am not working on the daemon, and also I am running GuixSD and have the daemon running.
<allana>So I definitely haven't been building the daemon or running it
<i1l>allana well, i may be messed something, but the procedure was: "build daemon, modify gnu/pavkages/some.scm, test with ./pre-inst-env".
<allana>I'm pretty sure that I am missing one or many things :-)
<allana>Is it actually necessary to build and run the daemon when modifying or adding packages in a checkout?
<allana>I'd love to know if anyone has written a tutorial other than the guix manual. Because I'm starting to think that it might need updating. I can't seem to build "hello" from a git checkout following the instructions found here:
<civodul>apteryx: hey! ping me when you're around so we can synchronize regarding the qt-build-system patches
<rekado>allana: yes, you need to build Guix when working with a checkout.
<abralek>Hi Guix
<rekado>allana: if you already have Guix installed you don’t need to run the daemon
<rekado>(I also don’t understand what i1l writes)
<rekado>allana: which step of the Contributing guide is problematic for you?
<rekado>the manual is authoritative and correct as far as we know.
<rekado>there shouldn’t be a need for any other resource.
<allana>rekado: "guix environment guix --pure" doesn't seem to provide what you need to build guix.
<allana>for example. after entering into this environment, running boostrap, and then "make" fails with "No Guile development packages were found.".
<i1l>allana wow, again. last time i run this command it worked as is ;)
<allana>and I can run guile from this environment, which boggles the mind.
<i1l>allana see, commiters use Guix as a toy. sometimes latest checkout is buggy.. everybody did ran into that. you may wish spend some time with the life, and then try again.
<allana>thanks i1l. I will probably do just that.
<roptat>allana, mh... weird
<roptat>did you run configure between bootstrap and make? :)
<efraim>allana: have you run './configure --localstatedir=/var --sysconfdir=/etc' first?
<allana>Although this means I'm a pretty unlucky guy, because this has happened to me every time that I have attempted to contribute a package in the right way.
<i1l>+1, then i striked luck 2 times.
<allana>efraim: I haven't run configure with those flags
<efraim>run that after ./bootstrap, it'll tell the guix checkout to use the same directories as the ones from the installed version of guix
<PotentialUser-37>I have this problem in send mail with git-send-email:
<PotentialUser-37>Command unknown: 'AUTH' at /gnu/store/0c96pd880gd7wxz3cf1yb67a4hg6cn4y-git-2.31.1-send-email/libexec/git-core/.git-send-email-real line 1573.
<efraim>hmm, gparted doesn't want to run under wayland
<allana>roptat: I think that you found my problem. I did not run configure, at least not recently :-) .
<roptat>allana, if make has issues finding some dependencies, that's because gc removed stuff from the store that the makefile references (because you run an environment, these items can be collected when you exit it), so you need to regenerate it, and that's what configure does, but it might also fail, so you need to regenerate configure with bootstrap
<roptat>basically, whenever you have an issue with make not finding something, run bootstrap, configure (with the flags shown by efraim), and make again :)
<allana>efraim and roptat: Thanks!
<morgansmith>rekado: I was looking at etc/committer.scm and I can't really figure out what it does. It always just spits out "Nothing to be done.". But I'm pretty sure that error message should have a newline? (line 256)
<morgansmith>efraim: Thanks for committing my patch! I'm very happy :D
<abralek>I am trying to run teams in flatpak but getting CERT_PKIXVerifyCert for failed err=-8179
<abralek>Has anyone tried to run teams like that?
<abralek>It seems like ssl doesn't work inside the flatpak
<abralek>nope curl does that
<morgansmith>As part of the GNU project, you won't get much help for proprietary software here. If you could reproduce the bug with some free software, that'd be ideal.
<abralek>but I found the issue =) ignore-certificate-errors=true, however I need somehow to proper add certs now.
<efraim>morgansmith: my self-hosted mail client doesn't like sending mail to your provider :/
<morgansmith>efraim: Ya I use outlook. I've been meaning the self host myself. Outlook doesn't let me configure the spam stuff and also changes the message-id of stuff I send for no reason meaning I can't make threads using git send-email. I really hate microsoft
<morgansmith>can you email google emails? I'd imagine the reputation requirements for google and microsoft would be about the same
<apteryx>is someone using Guix to develop on Qt applications here?
<apteryx>civodul: I'm here
<roptat>apteryx, does pyQt count?
<apteryx>does it use qtdeclarative/QML modules?
<apteryx>I think I've spot a problem where this doesn't work in 'guix environment' (just reported to the bug tracker)
<tricon>What's the stance on a project that is GPL but is utilized for interfacing with proprietary software? Specifically: open-vm-tools for use with VMware. I've built a package for our use as I wish to move our servers from Debian and Ubuntu to Guix and we utilize vCenter and ESXi hosts. Is this package worthy of submitting to the mailing list, or should it be withheld due to its ultimately intended use?
<apteryx>if it's free software (which seems to be the case), it can be packaged in Guix
<roptat>apteryx, no, I don't use QML
<tricon>apteryx: Thank you for the clarification.
<apteryx>roptat: OK, thanks. So you probably don't have any issue with Qt when working from a 'guix environment' or other profile, correct?
<roptat>no problem to report :)
<apteryx>good! thanks
<raingloom>ugh, how do i get an untruncated backtrace in the initrd guile?
<mbakke>why does "guix build icecat" produce a different store item than "guix package -I icecat | awk '{ print $NF }'" (after "guix upgrade")?
<roptat>you'll have to pass COLUMNS=500000000000 (or whatever huge value) somehow
<raingloom>roptat: initrd :)
<roptat>yeah, "somehow"
<apteryx>mbakke: not sure, but perhaps related to grafts?
<roptat>sorry, I have no idea ^^'
<raingloom>np, at least now i have a clue what variable to search for
<mbakke>apteryx: even with grafts they should be the same, no?
<apteryx>I'd think so, unless there's a presentation bug :-)
<apteryx>perhaps you can try 'guix build --no-grafts' and compare the result
<mbakke>apteryx: 'guix upgrade icecat' did the trick: it seems just 'guix upgrade' does not take grafts into account!
<apteryx>uh? That's bad
<roptat>oh, the download UI has an extra empty line between files, is that intended?
<roptat>though, it feels twice as fast :p
<mbakke>now I ran 'guix upgrade' again and got some new grafts, not sure what's going on ... hopefully I just messed up :P
<apteryx>OK :-)
<raghavgururajan>> ‎leoprikler‎: raghavgururajan: do you think your gstreamer stuff could make it to staging instead of c-u?
<raghavgururajan>I was hoping to get it to master, as it enables A/V support for applications that use farstream. Have to recheck the rebuilds.
<raghavgururajan>Hello Guix!
<rekado>morgansmith: etc/committer.scm looks at changes to files under gnu/, stages hunks that belong to modifications of existing package definitions, and commits them with a commit message that lists the relevant input changes.
<rekado>I’m using it a lot for CRAN / Bioconductor package upgrades.
<i1l>Hello raghavgururajan . Is Gnome 40 worth the trouble?
<i1l>seems as bad as before without a way to do mouseless.
<morgansmith>rekado: That sounds really cool. It didn't work with nano-lib but that's a weird package I guess. I'll play with it for some other packages sometime :)
<apteryx>i1l: if you like mouseless, you might prefer ratpoison. As its name implies, it was designed to part with the mouse.
<raghavgururajan>i1l: Absolutely! Having up-to-date GNOME with all features enabled, will be foster new comers and make guix deployable in machines of doctors, lawyers etc. Also, it is one of the DEs that provide good accessibility support.
<rekado>i1l: you don’t need to use Gnome. It’s a bit odd to ask if packaging something is worth the trouble when it clearly is a very popular package.
<raghavgururajan>My long-term goal is to make Guix an ubiquitous OS. For that, DEs are important.
<i1l>raghavgururajan heh? I hope it is better than Accessibility > Mouse Keys overally.
<i1l>plus many places have non enlargeable fonts...
*raghavgururajan was referring orcs integration, but yeah every software has some flaws and room to improve
<i1l>probably i need to go blind to aprettiate those ;)
<rekado>raghavgururajan: :thumbsup:
<i1l>btw, i seen "talking arch" recently. talking TTY!
<raghavgururajan>I see.
<i1l>Ok, gnome has a good Terminal at least.
<raghavgururajan>rekado: May I trouble you for creating a branch 'wip-gnome' on savannah? (
<civodul>apteryx: hi! :-) so, IIUC, i only need to add the QT WEBENGINE variable to the wrapper code, right?
<rekado>raghavgururajan: based on core-updates or master? Or some other branch?
<raghavgururajan>Hmm. Why is this message ( got separated from this thread (
<raghavgururajan>rekado: c-u
<raghavgururajan>rekado: Btw, it'd be great if you could review patches in #47643 and push them to new branch. Only if you are available though, if not no worries. :)
<apteryx>rekado: any idea why doesn't find issue #47655 but does ?
<apteryx>civodul: basically yes! Although I've found another qt issue: that I've been investigating
<raghavgururajan>civodul and apteryx: I think this issue ( is also related to Qt. My bet is that these Qt apps not able to use CA certs provided by qca package. So more wrapping?
<civodul>apteryx: ah! if you're on it, i can wait until you have a better idea of what's going on so we can decide what to do
<apteryx>OK, I'll keep you updated
<lafrenierejm>i1l: Thanks. I'd like to move to Sway eventually anyway, so this might be a reason to do so sooner rather than later.
<schmools>very much a beginner so pardon the kind of simple question but just installed guix for the first time and despite having as far as I know set up my user correctly in the config.scm file the only username I can log in under is root. Is there something else I need to configure with maybe GDM or is the issue perhaps elsewhere?
<PotentialUser-68>I keep forgetting to run `guix system reconfigure` with sudo. Just noticed that having run without sudo it fails at the very end with "Can't symlink in /var" probably as expected. But when I rerun with sudo it goes through all steps including downloading everything ... is this expected? I would've expected it to use whatever had been cached when I
<PotentialUser-68>attempted to reconfigure without sudo
<smartineng>Hello, I'm trying to build custom grub2 in "guix environment grub --ad-hoc font-gnu-unifont"
<smartineng>but it crash with "configure: error: qemu, coreboot and loongson ports need unifont"
<smartineng>any ideas how to fix it?
<rekado>apteryx: must be due to the way xapian is configured to stem and index words
<rekado>raghavgururajan: I’ll push wip-gnome shortly
<morgansmith>rekado: Your committer script wasn't working for me because the diff output was colored. Does git have a way to discard user preferences when running in a script?
<raghavgururajan>rekado: Thanks so much.
<rekado>morgansmith: yes, I should invoke “git diff” with that option
<rekado>morgansmith: thanks for letting me know
<lafrenierejm>schmools: Is there a specific error you're getting?
<raingloom>> probably i need to go blind to aprettiate those ;)
<raingloom>i1l: consider, you could use your computer even with a broken screen
<morgansmith>rekado: I think you should use git diff-files. It's a command that is more stable and meant to be used in scripts
<raingloom>i've had to install Ubuntu on a laptop with a trashed screen before. Orca was very useful for that.
<raingloom>curb effect in action.
<rekado>morgansmith: that’s a good idea, but I won’t change the script now. Feel free to submit a patch to improve it.
<i1l>raingloom did thee was forced to hit Tab key like mad, or UX was ok?
<morgansmith>rekado: Sounds good :) I'll take a crack at it
<i1l>my point was that Orca seems to be the only a11y feature that probably actually working in Gnome.
<raingloom>i1l: idk, it was about a year ago. some of the UI was fine, some was completely inaccessible.
<raingloom>magnifier and high contrast also worked last time i checked. but yeah, Guix needs to have better accessibility.
<leoprikler>raghavgururajan: gstreamer has at least 400-ish dependents, which normally makes it a staging candidate
<rekado>raghavgururajan: wip-gnome exists now; it’s just a copy of core-updates
<civodul>building the web site takes even longer now, i guess we really have to do something about it
<rekado>hmm, guix import cran -a git -r fails because the remote branch is not named origin/master.
<rekado>I remember bringing this up in the past. Not sure what to do about it.
<civodul>hey there!
<morgansmith>oh my that looks pretty useful. I don't have guix git log yet though, is someone merging it?
<morgansmith>I'm assuming that eww is not an expression of disgust but rather the Emacs Web Wowser :P
<tricon>morgansmith: Haha! Yes, you are quite correct.
<raghavgururajan>leoprikler: Ah, staging it is then.
<raghavgururajan>rekado: Thanks!
<raghavgururajan>leoprikler: Would you be able to review the gst patches and merge them to wip-gnome+staging?
<leoprikler>I don't think I'll be able to build stuff for wip-gnome on my machine, but I might try getting them to staging.
<leoprikler>They mostly LGTM when not looking at the indentation changes :)
<raghavgururajan>Any step forward is good. So getting it to staging is good. I can ask lle-bout to merge to wip-gnome later.
<raghavgururajan>Ah, the indent.el script applies the indentation to whole package definition. But the if commit only selected lines, those lines look odd.
<leoprikler>I mean specifically stuff like 18/22, which becomes obsolete through 20/22
<leoprikler>also, I personally disagree with the way emacs forces single line comments to be at an arbitrary column
<leoprikler>also, I don't think your synopses and descriptions are really fitting. They sound more like advertisement speech than something I'd expect from Guix.
<rekado>raghavgururajan: the indent script takes a package definition name as an argument, so you should be able to restrict it to just one definition
<leoprikler>they did that, but they still need to better review the diff indent.el generates
<leoprikler>some changes are just noise
<apteryx>rekado: I see! Thanks.
<morgansmith>rekado: oops, just saw your --no-color commit. That patch I sent that uses diff-files doesn't need the --no-color flag.
<rekado>morgansmith: oh, you’ve sent a patch already?
<morgansmith>rekado: check your email :) it's super small but it took a long time of sleuthing through man pages to make
<rekado>morgansmith: excellent!
<rekado>I’ll check it later tonight. Gotta make some pizza now.
<morgansmith>rekado: No rush :) I'm glad I found that tool. It should probably be documented so more people use it.
<leoprikler>Ehm, is "which" the correct procedure to do lookups when cross-compiling?
<lfam>i1l: I don't understand the question you asked me
<lfam>i1l: I think I understand your question now, although I'm not sure why I bothered
<lfam>I would say you need about 1.5 GB RAM for Guix
<i1l><lfam "i1l: I think I understand your q"> sorry, i thought you're man.
<i1l><lfam "I would say you need about 1.5 G"> tx.
<apteryx>Can we delete the wip-rust branch? It hasn't seen new dev for 2 years.
***sneek_ is now known as sneek
<civodul>sneek: later tell apteryx perhaps efraim knows better, but my guess is that we can delete wip-rust and see what happens (it can always be recovered at worst)
<sneek>Will do.
<leoprikler>1 passed, 1 failed, 1 unknown
<apteryx>civodul: how long is that? (building the website?)
<sneek>apteryx, you have 1 message!
<sneek>apteryx, civodul says: perhaps efraim knows better, but my guess is that we can delete wip-rust and see what happens (it can always be recovered at worst)
<apteryx>civodul: I think you can go ahead with the qt fix; the problem I was investigating may not exist in Qt 6 (they changed how QML modules are imported)
<apteryx>so I'll want to verify if it still exists there before attempting to fix it for Qt 5.15.2 (which will take some time)
***lukedashjr is now known as luke-jr
<efraim>Probably. I don't even know what's on that branch now
<lfam>New substitution UI!
<lfam>It's an improvement IMO
<lfam>Maybe it was nice to see the store paths, idk
<roptat>on master? is that why I thought it was different today?
<roptat>is the empty line between substitutes intended?
<leoprikler>I'm sure we'll all get used to it at some point, but it does feel as though it takes up more space than needed
<roptat>I don't complain, but I don't see the point of having empty lines
<roptat>well, I complain, but lightly
<ryanprior>This is awesome, would be great to have something similar for each Guix package, service, and debbugs issue
<roptat>not sure I get it, what is that?
<lfam>I don't see any empty lines from here. This is based on 37d8def701839200c44c76cb2fa2abfb27a7b88b (from yesterday)
<roptat>well I do, on 37d8def701839200c44c76cb2fa2abfb27a7b88b too
<roptat>my daemon might be slightly older
<lfam>I updated the daemon too
<roptat>mh... hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is a12de215e3e744e2fc4cbb33ca0b2a7b48c22405.
<roptat>I'm pretty sure I pulled on the root profile after the last security issue
<apteryx>efraim: it seems to have been about the initial source rust bootstrap
<roptat>I don't remember, should I "sudo guix pull" or "sude -i guix pull"?
<lfam>sudo -i
<apteryx>on guix system?
<lfam>Aka `sudo --login`
<roptat>foreign distro
<lfam>Plain sudo puts you in a weird state where you are not any particular user
<jonsger>I do usually a sudo -E :P
<lfam>That works too
<lfam>`sudo -i` makes you root. `sudo -E` leaves you as 'roptat' but with privileges
<lfam>Plain `sudo` makes you into a ghost
<leoprikler>sudo -u ghost :P
<roptat>oh, the manual say "sudo -i", I'll trust that
<lfam>It's a problem for Guix, which relies heavily on login shell initialization to set up the environment and give you the per-user "view"
<jonsger>the things is I don't wanna have a "per-user view", as I'm the only physical one on my systems...
<roptat>ah indeed, with a newer daemon, no blank lines
<apteryx>I've tried merging master into staging, and now attempting to build it leaves me with: error: failed to load 'gnu/tests/install.scm': No such file or directory, although the file exists. Mmm.
<apteryx>this after make distclean & friends
<lfam>jonsger: Well, yeah :) But per-user package management is one of the main points of Guix
<lfam>If you are on another distro, you can take guix-daemon from your own user and ignore the root user completely
<lfam>apteryx: Maybe you need to ./bootstrap again
<lfam>That usually solves spooky build issues for me
<jonsger>yeah, I know that its a feature. But I wanna have it "disabled as far as possible" to avoid duplication etc...
<lfam>Right. Then I'd do what I suggested, use your user's guix-daemon. You might even be able to remove root's Guix profiles completely
<apteryx>lfam: I tried already :-)
<lfam>Huh :)
*apteryx tries ./pre-inst-env guile -l gnu/tests/install.scm
<lfam>By the way, can we make some release candidates this weekend? vagrantc was asking for an RC of the source tarball
<lfam>The installer image is already built on CI, if I understand correctly
<lfam>I'm not sure about the binary installer of the package manager
<apteryx>yes it'd be a good way to oil the machine
<lfam>When do you think you'll have time to make them?
<apteryx>I can try from Friday evening
<lfam>Alright. I'll be around
<ryanprior>roptat: the tweet shows custom-generated "social media cards" that show information about a linked repository, issue, or commit in GitHub
<ryanprior>posting again for others following along:
<roptat>ryanprior, this thing: ?
<ryanprior>You create those by generating an image and putting the desired title & image link into special markup on the page, then social media platforms will pick up on that and create a "card" out of it to show alongside the post containing the link.
<roptat>ok, I wasn't sure if that was it, or just twitter creating a custom preview for github
<roptat>oh, so that's github providing an image to twitter
<ryanprior>Twitter doesn't generate it, they use an open standard to find the desired info & display it.
<ryanprior>Mastodon uses the same standard:
<roptat>alright, understood!
<ryanprior>Discourse uses them too, and I'm sure other free software social platforms.
<roptat>not sure how to generate png from guile though ^^'
<apteryx>lfam: cool!
<lfam>I pushed your QEMU perf patch!
<apteryx>I think the problems I'm having building staging after the merge of master are somehow caused by autoloading
<apteryx>I get messages such as: WARNING: compilation of guix/diagnostics.scm failed:\nUnbound variable: trivial-format-string?
<ryanprior>roptat: we've got guile-cairo in guix, I imagine we can generate PNGs that way
<apteryx>when doing ./pre-inst-env guile -l gnu/tests/install.scm
<cbaines>evening all o/
<leoprikler>hmm, this card thing looks like something that can easily exploited for XSS, doesn't it?
<leoprikler>s/can easily/can easily be/
<ryanprior>leoprikler: yes, it could be a vector for sure, displaying cards is a risky business.
<ryanprior>I think it's a manageable risk, stock data-sanitation and anti-XSS practices should suffice, but there's no doubt a risk since you're inviting foreign data onto your page.
<jeko>Hey Guixters!
<sneek>jeko, you have 1 message!
<sneek>jeko, Thunderbi says: Did you reboot (or perhaps you need only to relog in) after adding yourself to kvm? Is the kvm kernel module modprobed?
<roptat>well, generating the card is also risky, no?
<roptat>after all, displaying it triggers some code that reads data
<jeko>I am having difficulties to get the hash of my project with guix hash
<jeko>I called the following command inside my project's folder: guix hash --recursive --exclude-vcs .
<jeko>But the hash is not the same I get in the guix build error
<roptat>maybe you have files that aren't present when you create a clean clone of your project?
<jeko>interesting point ^^"
<jeko>Oops gitignore trap!
<leoprikler>you should be able to generate the card using local info only
<leoprikler>i.e. generating on the site that's linked amounts to setting some headers
<leoprikler>the potential XSS vector is interpreting those headers on twitter's end
<jeko>roptat: Thank you! I let dotfiles lying around
<apteryx>lfam: eh, I completed the merge in magit, and now it seems to build fine. I guess there were temp files caused by having resolved conflicts or something related.
<ryanprior>There is some risk in generating the card at all. Supposing there's some data that causes misbehavior when you tell `cairo` to render it as a string, maybe that misbehavior could give RCE on the server generating the image.
<ryanprior>Again, data-sanitation and sandboxing would be prudent. Hopefully the Guix issue tracker is already doing some sanitation (but I haven't checked)
<atuin>did anyone manage to install guix on raspberry?
<lfam>atuin: Which raspberry?
<civodul>apteryx: so i'll push the qt-build-system patch i sent and add QTWEBENGINEPROCESS_PATH to the wrapper variables on your behalf
<bone-baboon>When I try to build a Haskell program with Cabal (a Haskell build tool) using the command `cabal new-build` I get this error:
<bone-baboon>"/run/current-system/profile/bin/ld: cannot find crti.o: No such file or directory"
<bone-baboon>"collect2: error: ld returned 1 exit status"
<bone-baboon>"`gcc' failed in phase `Linker'. (Exit code: 1)"
<bone-baboon>crti.o is not in the output of `locate crti`.
<bone-baboon>What package provides `crti.o`?
<bone-baboon>I do not see a relevant package when search using `guix search crti`.
<roptat>ryanprior, I agree it'd be nice :)
<civodul>bone-baboon: you probably need to install the 'gcc-toolchain' package
<lfam>cbaines: For your Honeycomb, have you selected an enclosure? I've never "built a PC" before so I don't really know how to start shopping for these things
<civodul>lfam: ooh, great that you're doing this!
<lfam>I'm trying to put together a "parts list" for final approval
<cbaines>lfam, no, I was planning to find a case, power supply, RAM, ... and was holding off until I knew it had shipped
<lfam>I'm going to contact the Solid Run sales dept, to see if they actually have these things on hand
***atuin- is now known as atuin
<bone-baboon>civodul: Thanks I will try that.
<roptat>ryanprior, I tried guile-cairo, but I don't understand how to create an image, I see cairo-image-surface-create takes a format-type as its first input, but I have no idea how to define one
<roptat>er, cairo-format-t precisely
<ryanprior>Oh darn I wouldn't know either, I'd need to find some example code
<ryanprior>It looks like guile-rsvg depends on guile-cairo, that could be a source of info
<mihi>Noisytoot, if you want to change the keymap for the Hurd console (which is just a normal userspace process that talks to your keyboard, mouse and vga text screen), you'd have to find out where your hurd system launches it (I assume from shepherd) and pass it the --keymap option. Note that the xkb keymap patches are not part of upstream Hurd console, but e.g. Debian's version includes them.
<mihi>so not sure how patched Guix' Hurd console is
<ryanprior>It might actually be a better API for our purposes of creating informational cards too, SVG is fairly nice to work with and you'd be spared working with the low-level cairo primitives.
<apteryx>civodul: sounds good
<apteryx>any idea what the way forward qt 6 will be? should we rename all qt* packages to qt*-5 ? e.g., qtbase -> qtbase-5, then qtbase becomes at version 6
<Noisytoot>mihi, are the patches included in guix?
<mihi>I never was able to get Guix hurd to run as I like it (for more than e.g. 2 hours when I broke it), so tbh I don't know.
<rekado>roptat: I use guile-rsvg to generate PNG from SVG.
<rekado>I have example code in guile-picture-language
<mihi>Noisytoot, how is substitute availability for Hurd right now? enough to guix system reconfigure from inside?
<PotentialUser-80>When using the Guix package manager on a foreign host system, can you install other window managers using Guix and have it work on the host system?
<lfam>You can, yes
<lfam>It may take some work
<Noisytoot>mihi, I think substitutes are available, but I ran out of disk space when installing a package
<PotentialUser-80>lfam, How would you get the hosts login manager to see it though?
<Aurora_v_kosmose>PotentialUser-80: Symlinks.
<lfam>PotentialUser-80: I don't know. This is the work I mentioned
<PotentialUser-80>Okay, thanks for the info.
<civodul>apteryx: and indeed, a quick grep shows that QTWEBENGINEPROCESS_PATH is set in many places
*apteryx just merged master into staging
<bone-baboon>civodul: I tried adding gcc-toolchain to my system configuration and reconfiguring. However there is still the same error. I aslo tried glibc but the same error presists. `crti.o` is now in the store in several places.
<apteryx>civodul: yes, but we'll have to be careful adapting only those for packages using the qt-build-system
<civodul>i'll leave it as an excercise for the commit reader :-)
<lfam>5 years of projects like Guix not being able to reliably get CVE IDs assigned:
<Aurora_v_kosmose>Login required.
<lfam>I highly recommend subscribing to LWN!
<Aurora_v_kosmose>Do they take IOUs?
<lfam>No, just money
<lfam>I can't believe we got an LWN article before a CVE ID
<lle-bout[m]>lfam: heh..
<Noisytoot>Why can't guix get CVEs?
<civodul>lfam: fun :-)
<civodul>maybe the LWN article will give MITRE an incentive to improve its processes
<lfam>Noisytoot: Because the only way for independent projects to get CVE IDs has basically shut down
<lfam>I hope so civodul, but I'm pessimistic. It's been like this for 5 years, with lots of public attention
<Aurora_v_kosmose>An alternative might be required.
<lfam>MITRE seems more interested in enforcing their trademark on "CVE" than actually managing the program
<lfam>I'd guess the MITRE board was sacked around... February 2016
<lle-bout[m]>raghavgururajan Hello! I saw your patch submission, I will review soon!! :-) You used git-send-email awesome!!
<Aurora_v_kosmose>How do they even still have a trademark given how much it has become common speech?
<lfam>There's a difference between "common speech" and losing a trademark
<lfam>Ultimately, the only way you can "lose" a trademark is in court
<lfam>Until they lose a court case, they can still try to enforce it, as they are doing
<Noisytoot>lfam, What's the point of CVEs anyway?
<Noisytoot>Can't you create your own CVE like things
<lfam>To keep track of specific bugs, so that the software industry can coordinate
<lfam>Sure, but it's better to have one standard than a dozen
<Aurora_v_kosmose>Noisytoot: Documenting vulnerabilities so that you can be aware of dangerous dependencies in your graph.
<lfam>A lot of vendors do use their own IDs, but the CVE database is still the most comprehensive
<lfam>For Guix, and this bug, it doesn't really matter. Guix isn't something that you re-use, like a library
<lfam>But it's still best practices to get these IDs when publicizing the bug
<leoprikler>meh, I'd rather have a website with a fancy logo and a shot glass
<lle-bout[m]><lfam "For Guix, and this bug, it doesn"> You could!
<lfam>We'll all need a shot glass after this saga is finally over
<lfam>Yeah, you could. But Guix not like OpenSSL, for example
<lfam>Almost every use of Guix is self-upgrading, and doesn't require some other vendor to take action
<Noisytoot>lfam, what's the bug?
<Noisytoot>I can't see the LWN thing
<lfam>I shared a link Noisytoot
<lfam>A free link
<pkill9>what is the saga?
<lfam>But, I highly recommend subscribing! It's the best source for news for our world :)
<lfam>The saga of begging random agencies of the US govt for a CVE ID
<lfam>And then it turning into a news article
<Noisytoot>2 security issues
<Noisytoot>there's also the new user guix system one
<lfam>I don't think we'll bother trying to get a CVE ID again
<lfam>It's only been 5 years like this
<Noisytoot>hard links are evil
<lfam>That bug wasn't specifically about hard links :/
<Noisytoot>would it be possible without hard links?
<lfam>The hard link thing was just an example
<lfam>It was more about the difficulty of safely changing ownership of arbitrary files
<lfam>Unix doesn't have a way to do this. You have to jump through a lot of hoops to do it safely
<Noisytoot>lfam, cat: /proc/sys/fs/protected_hardlinks: Cannot allocate memory
<Noisytoot>when I run it as root
<Noisytoot>how can I view /proc/sys/fs/protected_hardlinks
<lfam>It works for me
<lfam>We are not experts on writing security advisories. The vulnerability can be considered to be quite general, but we only described a particular exploitation vector
<jackhill>There's also the other part of it, a healthy vulnerability database makes it easier for us to track things that need to be fixed in the package collection.
<lfam>Centralization is the way
<Noisytoot>lfam, I get that for all files in /proc/sys/fs
<lfam>Are you out of memory?
<jackhill>I wonder if there could be some cross-polination with library or wikidata people. I think they have a lot of experience dealing in identifiers
<Noisytoot> total used free shared buff/cache available
<Noisytoot>Mem: 3.6Gi 2.5Gi 283Mi 303Mi 784Mi 287Mi
<Noisytoot>Swap: 3.8Gi 3.7Gi 73Mi
<lfam>I don't know
<lfam>I can't reproduce it on Guix System
<lfam>You could use `sysctl fs.protected_hardlinks`
<Aurora_v_kosmose>How does Guix fare security-wise?
<lfam>But, like I said, this is only tangentially relevant to that bug.
<lfam>The fix was in guix-daemon
<lfam>That's a very broad question
<Aurora_v_kosmose>As time goes I've been looking at it with more interest as my main distro.
<lfam>You'd have to try to define what security is. Like, what is your threat model? And what are your alternatives?
<Aurora_v_kosmose>Currently with Debian.
<Aurora_v_kosmose>Thing is, packaging things for Debian is like pulling teeth.
<lfam>You can model security as Confidentiality, Integrity, and Availability. Guix makes certain things, like packaging, available in a way that they are not on Debian
<lfam>You could use a different distro and lose a lot of things
<PotentialUser-28>Hello! Looking into GNU Guix as my new daily driver, i have skimmed the manual and have some general questions regarding hardening options for the GNU Guix System. To what extent can the full guix system be built using the clang toolchain+musl (similar to the hardened gentoo and void linux builds)? I cannot find documentation for using MAC with the
<PotentialUser-28> full system, is the Guix System compatiable with selinux or apparmor? I am a bit lost as to how to apply hardening options to the kernel build process, what sections of the manual should i be looking at for understanding how to pass options to the kernel build process?
<Noisytoot>lfam, I'm using Debian
<lfam>PotentialUser-28: There is no generic mechanism in Guix for achieving the tasks you are asking about
<Noisytoot>sysctl fs.protected_hardlinks works
<Noisytoot>fs.protected_hardlinks = 1
<lfam>If you want to use a custom kernel, PotentialUser-28, you should check this blog post:
<lfam>Noisytoot: That option is enabled on pretty much every distro. Guix was an outlier in having not enabled it
<Aurora_v_kosmose>lfam: Guix seems, by default, to have better scores on all but the first.
<lfam>How's that?
<Noisytoot>lfam, Is it enabled now?
<Noisytoot>Why isn't it enabled?
<lfam>Yes Noisytoot, since mid-March
<lfam>Well, there are people who knew about it, and people who work on Guix, and those groups never overlapped :)
<Aurora_v_kosmose>Well, depending on what you mean by integrity. Package integrity guarantees for Guix are at least as strong as Debian's, some better due to slightly better reproducible builds. Availability is guaranteed by substitutes fallback.
<lfam>Right, for each of these properties, we can apply them to different tasks we want the computer to perform. It's why I said your original question was vague :)
<Aurora_v_kosmose>For the first it makes me wonder if there's actually the possibility of having Guix fetch stuff over Tor or whatever other overlay network you want.
<lfam>I'd say that package integrity has been better than Debian for a while
<lfam>I think the idea of "packages over Tor" in an interesting example for threat modeling
<lfam>To me, using Tor at all makes you stand out from the crowd
<lfam>Whereas fetching packages over HTTPS is utterly normal
<lfam>So, it really depends on what one is trying to protect against
<Aurora_v_kosmose>I'd expect more people to regularly use Tor or I2P here to get around censorship, than for them to be pulling stuff directly from GNU domains.
<Aurora_v_kosmose>But assuming that this doesn't provide additional privacy over TLS, it does make it harder for the GNU server, if it were compromised, to identify a single user.
<lfam>Well, if you don't trust the server, then all bets are off
<lfam>Although, the types of attacks that the server can perform only get harder as we improve the client-side code authentication mechanism
<Aurora_v_kosmose>I generally trust GNU itself a fair bit, but I'm also quite aware that GNU is a very visible and tempting target.
<lfam>Indeed. And lacking resources
<lfam>The Guix security model is that the server is not trustworthy, even our Git server
<lfam>But it's a work in progress and could use some real testing
<lfam>I guess that "all bets are off" was too strong a statement. It reflects the reality of a few years ago, but not the present
<lfam>I'd still like to see some bugs discovered in this area... there must be some
<PotentialUser-28>Thanks Ifam, the blog post is very useful. Generally can the tasks i asked about be achieved with guix? Basically i want the system to have a comparable security posture as hardened gentoo. I am ok with having to figure out how, but as i am new to lisp and transactional package managers i am hesitant to invest the days/weeks/months(??) without know
<PotentialUser-28>ing if its even possible
<lfam>Like, we were confident in the build chroot... and then a bug was discovered :)
<lfam>PotentialUser-28: The sky is the limit with Guix. The entire system's source code is made available in an integrated software development environment
<Aurora_v_kosmose>PotentialUser-28: In some cases they aren't implemented yet, but there's nothing which fundamentally makes them incompatible.
<lfam>However, you would have to do pretty much all the work to achieve your goals, and it might be a lot of work. Especially the apparmor thing
<lfam>Oh, I didn't notice that you want to use musl. That might not really be possible. Guix is heavily based on glibc
<lfam>By the time you were done, it would justify a name change
<lfam>Like, how Guix was born from Nix
<Aurora_v_kosmose>I could imagine a custom pull task/hook which regenerates system configs for all users by crawling profiles to generate apparmor profiles from templates.
<lle-bout[m]>I would be curious to grow a new GNU Guix package set from scratch
<Aurora_v_kosmose>My experience so far with Guix is that it's about as easy to contribute to as the AUR. Which is partly what has me so... disappointed with Debian lately.
<lfam>I've never tried to use Arch / AUR. Are you saying that it's easy to contribute to Guix?
<Aurora_v_kosmose>lfam: Yes, I am.
<lfam>Great :) That's what we want
<lfam>Let us know how to make it easier
<pkill9>Aurora_v_kosmose: i too want sandboxed and hardened guix
<Aurora_v_kosmose>Both are a stark departure from Debian's.
<pkill9>someone was asking about this yesterday
<pkill9>and I've been thinking about it for a while, generated apparmor/selinux profiles would be great
<Aurora_v_kosmose>On my VM servers I rely on libvirt's ability to generate apparmor/SELinux sVirt profiles automagically.
<Aurora_v_kosmose>That's what gave me the template idea.
<pkill9>currently I use firejail for sandboxing which honetly is probalby not even worth it, because it introduces privacy escalation potential
<pkill9>I have applications have their own directory in ~/.appdata which is set to HOME for them
<pkill9>and they can only access that directory, plus a shared files directory
<pkill9>that's the kind of setup I want