<gchristensen>
!!! I spent ages looking for official qcow's from fedora/centos/debian and didn't find those!
<Dezgeg>
the magic keyword was 'openstack' iirc
init_6 has quit [Ping timeout: 240 seconds]
<Dezgeg>
I can't recall exactly what it was but I think most of those vagrant images had something hardcoded such that they would only (easily) boot on virtualbox
* gchristensen
deletes a lot of vagrant-to-qcow code
init_6 has joined #nixos-dev
Drakonis has joined #nixos-dev
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
<gchristensen>
Dezgeg: your commit there has been hugely helpful, thank you :)
erickomoto has joined #nixos-dev
erickomoto has quit [Client Quit]
erickomoto has joined #nixos-dev
lassulus_ has joined #nixos-dev
erickomoto has quit [Client Quit]
init_6 has quit [Ping timeout: 244 seconds]
lassulus has quit [Ping timeout: 260 seconds]
lassulus_ is now known as lassulus
<aszlig>
samueldr: oh wow... i can reproducibly read even the passphrase from the old implementation
<aszlig>
samueldr: for the new implementation the passphrase just occurs more than once in memory
<samueldr>
uh, let's say: glad there aren't regressions?
* samueldr
is a bit spooked
<aszlig>
the old variant had the password in kernel space
<aszlig>
now it's in userspace
<samueldr>
ah, so kindo f
<samueldr>
I guess the kernel ones aren't avoidable?
<aszlig>
samueldr: i stepped through with gdb and radare and it's actually the input buffer for the tty
<samueldr>
I like the way it's a nixos test
<samueldr>
aszlig: do you know if their assumption was right? > However, AFAIK, with Linux that memory will be zeroed out anyway before being reused by any process after `ash` `exec`s into the next stage
<samueldr>
tried a bit of google search but found nothing even remotely close to being relevant
init_6 has joined #nixos-dev
<gchristensen>
samueldr: link?
<aszlig>
samueldr: okay, i was wrong it's still only once
<aszlig>
samueldr: maybe i have to do several test runs
<samueldr>
aszlig: if I can do anything to help, do ask (though you seem to have more knowledge in the area)
<samueldr>
oh, gchristensen, last comment is the assumption I was talking about
<gchristensen>
and the nixos test is searching memory for the password?
<samueldr>
it isn't currently, but aszlig just wrote one
<aszlig>
but already having the passphrase even in kernel memory is something that makes me feel a bit uneasy... i mean what are all those kernel patches to defend against cold boot attacks worth trying to defend against key exposure if the passphrase is simply in memory?
<gchristensen>
ahhhh amazing!
<aszlig>
samueldr: okay, it's really only once
<aszlig>
so that PR at least didn't make things worse
<samueldr>
I'll be able to sleep tonight (joking)
<samueldr>
though, still worrying how it's apparently in the kernel memory (if I understand correctly)
<samueldr>
wondering if there is something other distros do
<aszlig>
hm, otoh... this could also be userspace, investigating...
sir_guy_carleton has joined #nixos-dev
<aszlig>
(which also wouldn't make sense for the tty input buffer)
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
init_6 has quit [Ping timeout: 244 seconds]
Drakonis has quit [Remote host closed the connection]
erickomoto has joined #nixos-dev
erickomoto has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
init_6 has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
garbas has quit [Ping timeout: 248 seconds]
garbas has joined #nixos-dev
garbas has quit [Ping timeout: 272 seconds]
garbas has joined #nixos-dev
garbas has quit [Ping timeout: 240 seconds]
garbas has joined #nixos-dev
vcunat has joined #nixos-dev
genesis has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
garbas has quit [Ping timeout: 272 seconds]
garbas has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<gchristensen>
I'd take the commit message as strong feedback and put it back with a good error message
<samueldr>
any opinions about saving the stateVersion in a stateful directory and comparing it for a warning/plain stop?
<samueldr>
as many stateVersion-gated things require manual intervention, I feel it's fine to require manual intervention (deleting the stateVersion.lock(?) file)
<samueldr>
here, assuming absence is fine
<infinisil>
samueldr: Would need to be a runtime thing then
<infinisil>
Because build machine != deploy machine
<samueldr>
oh, right
<samueldr>
(which is why I'm asking!)
<infinisil>
But I thought about this before, and if it wasn't for that, I'd prefer such a state file
<samueldr>
too many times stateVersion seems to be changed "to upgrade"
<infinisil>
Yeah
<infinisil>
I think it would be better for it to just be an increasing integer
<infinisil>
And every time somebody does a change that requires a state update, they increase the number
<infinisil>
E.g. postgres default location upgrade -> increase number
<samueldr>
infinisil: this becomes a bit messy, though, with parallel long-lived branches
<infinisil>
Oh true
<gchristensen>
a number isn't really good either because you may wantto upgrade part but not all the things
<samueldr>
yeah
<infinisil>
Okay, well it should really be such a state number *per module*
<infinisil>
or per service or whatever
<samueldr>
though the incrementing number has one advantage: each increase can be documented more plainly
<samueldr>
it would become messier, but in the long run, probably much less confusing
<infinisil>
If it's per-service, then you don't even have to bother with it if you don't use such services
<samueldr>
(for the end-user)
<samueldr>
yeah, imagine my media-consumption computer, pretty sure stateVersion there is a no-op
<timokau[m]>
Is there a way to mark a package as binary (not built from source)?
<infinisil>
timokau[m]: preferLocalBuild might be worth setting
<infinisil>
(Or whatever the attr is called)
<infinisil>
And/or allowSubstitutes = false (not entirely sure how that differs from preferLocalBuild)
<infinisil>
Though)
<vcunat>
That does differ.
<vcunat>
One is about checking if a substitute exists.
<LnL>
that's substituters vs build-remote
<vcunat>
And one is about whether the build is distributed.
<infinisil>
Ah right
<LnL>
most things set both tho
<vcunat>
Yes, I can't remember any use case for not keeping them at once :-)
<LnL>
aren't sources only dontSubstitute?
<LnL>
ie. download from upstream, but do it on a remote builder since it will need to be copied there anyway for the build itself
<vcunat>
sources are substituted typically
<vcunat>
oh, but not via binary cache :-)
<vcunat>
I easily forget about that distinction
<vcunat>
but the state is that fetchurl has preferLocalBuild = true;
<vcunat>
only!
<vcunat>
Anyway, any reason not to mirror (some) sources via the standard binary-cache mechanism?
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
Cale has quit [Read error: Connection reset by peer]
timokau has quit [Quit: WeeChat 2.1]
<LnL>
I'm not sure why we have the distinction between substituting sources as a build and tarballs.nixos.org
Drakonis has joined #nixos-dev
<vcunat>
there's a thread about that somewhere already
lopsided98 has quit [Ping timeout: 255 seconds]
lopsided98 has joined #nixos-dev
timokau has joined #nixos-dev
<LnL>
I wouldn't call copumpkin's email a thread, or are you thinking of something else?
<vcunat>
Probably, I do remember copumpkin raising that.
<timokau[m]>
I feel like there should be a meta variable marking this. I care far more about weather or not the software I installed was build from source than I care about the license
Cale has joined #nixos-dev
disasm has quit [Quit: WeeChat 2.0]
<LnL>
that's not really related but yeah that would be cool
<LnL>
bootstrap-tools is an interesting case tho :)
vcunat has quit [Quit: Leaving.]
<timokau[m]>
Well thats how I started the discussion so kinda related :)
<timokau[m]>
Yeah I don't know the details about that but you have to start somewhere. You'd probably need to make an exception for that.
<timokau[m]>
But I'm assuming those are as minimal as possible
<LnL>
yeah, otherwise it would propagate to everything if you disallowed binary packages :p
<timokau[m]>
The best cyber-security policy is still to trash the computer and move to a remote cave
<MichaelRaskin>
You forgot to EMP the surroundings of the cave
<MichaelRaskin>
There are many compilers, and many of them need binary bootstrap…
<timokau[m]>
Are there really that many? I thought most would just bootstrap from c
<clever>
ghc cant be compiled from c
<MichaelRaskin>
Haskell, Common Lisp, Pascal, Rust…
<timokau[m]>
Thats haskell right?
<clever>
yeah
<timokau[m]>
Huh, I thought rust was bootstrappable without binary
<MichaelRaskin>
I think Go bootstrap from C keeps getting more and more stages
<clever>
and for extra fun, certain versions of ghc need certain versions of ghc
<timokau[m]>
How do they come up with the first version then? Still hand-compiling?
<clever>
so you have to compile 3 different ghc's to get the most recent one
<timokau[m]>
Its a hard problem, but at least we can automate it
<MichaelRaskin>
Well, back in the day some old version was compilable from C
<timokau[m]>
MichaelRaskin: Isn't that exactly how bootstrapping works? Compile that old version from C, compile the next version from that...
<timokau[m]>
Ideally you won't have to compile every version of course
<infinisil>
I don't think boostrapping says anything about where to start
<infinisil>
You can go arbitrarily back if you want to, back to compiling gcc with the first version of the C compiler written in assembly or whatever :P
<infinisil>
Just not very practical
<MichaelRaskin>
With some of the compilers, the last version compiled from other language can even be before the current repository origin
<MichaelRaskin>
(or maybe interpreted and used to self-compile)
<timokau[m]>
infinisil: Maybe not practical for everyday use, would be very neat to have the option though ^^
<clever>
MichaelRaskin: the rust compiler maps \n to the value of '\n', lol
<clever>
so it assumes whatever is compiling the compiler knows what \n is
<MichaelRaskin>
\v: the same, in many languages, but not many people remember what the hell this even is
<timokau[m]>
clever: Thats amazing / a bit horrifying
<timokau[m]>
MichaelRaskin: don't leave us hanging, what the hell is it?
<clever>
vertical tab i'm guessing?
<timokau[m]>
Where would I use a vertical tab?
<clever>
good question, lol
<MichaelRaskin>
timokau: obviously if you target a self-compiling compiler, the bootstrap interpreter is destined to have a lot of weird limitations (because you want to get something one-shot quickly)
<MichaelRaskin>
The answer is nowhere anymore, because the terminal emulators, unlike programming languages, are way less eager to propagate ^K support
<clever>
MichaelRaskin: which would be why the bcompiler.html above started with an assembler that cant even fill in addresses of nearby symbols
<MichaelRaskin>
Maybe because they need to do actual work
<simpson>
MichaelRaskin: Monte deliberately killed '\v'. We couldn't find any usage of it in Python codebases, other than to propagate Python's support for it.
<MichaelRaskin>
And releasing such a tool that never works right except with one specific revision of the compiler codebase…
<MichaelRaskin>
simpson: yes, some languages do make a sanity check and then throw away \v
<MichaelRaskin>
(Personally, I do have some code using ^K character)
<clever>
MichaelRaskin: ive also seen ^L in some codebases
<clever>
that tends to screw with auto-complete in vim for some reason
timokau has quit [Quit: WeeChat 2.2]
<clever>
timokau[m]: we lost half of you! lol
<timokau[m]>
clever: What do you mean you lost half of me?
<MichaelRaskin>
^K I use for some automation logic: if I want to send Tab, I put ^I, and ^K for Shift-Tab
<clever>
timokau[m]: timokau disconnected
<timokau[m]>
clever: Oh right, thats weechat running on my raspberry pi
<timokau[m]>
clever: Before I switched to mostly using matrix, I always used weechat on a always-on rpi as a poor mans solution for persistent logs
<timokau[m]>
Now that is still running because why not
<clever>
timokau[m]: ive got irssi + screen on an old box
<timokau[m]>
And I just restarted the raspberry pi because I'm experimenting with wireguard
<timokau[m]>
clever: I had weechat+tmux, thats like the 2nd gen technology version of your solution :D
<timokau[m]>
(Not saying that irssi or screen are worse)
timokau has joined #nixos-dev
Jackneilll has quit [Read error: Connection reset by peer]
Jackneilll has joined #nixos-dev
<timokau[m]>
Back to topic: generalizing the "is binary" one, something like f-droids anti-features might be nice one day
<Drakonis>
that's very ad hoc and could use expansion
<samueldr>
timokau[m]: please write an RFC for this, or at least some words on the discourse, but I agree with the general idea
<samueldr>
and not even creating a judgement about whether binary is good or not
<samueldr>
just documenting it
<timokau[m]>
clever: I'm not sure if I care strongly enough for an RFC, maybe I'll do that some time
<timokau[m]>
Especially because they tend to end up nowhere anyways
<samueldr>
hi, I'm samueldr :)
<timokau[m]>
But a discourse thread is little effort and a good idea
<samueldr>
which is why I continued with "or at least a thread"
<timokau[m]>
samueldr: hi samueldr, I'm timo?
<samueldr>
(related to the fact that the tab-completion completed with the wront name)
<timokau[m]>
Oh, I messed up the mention
<samueldr>
(I personally know how RFCs can be tiring and seem to go nowhere fast, but still believe in the concept)