<nh2>
finally, I get "reset secure session" all the time (there was also a recent blog post by matrix.org pointing that out about Signal), which means I need to recheck key fingerprints manually all the time (like literally every couple days) if I don't want to blindly trust the server
<nh2>
but then, matrix.org can't keep their Jenkins updated either and get owned, so the whole "send secure messages" world is just a shit show right now compared to what it could be
<gchristensen>
+1
<infinisil>
So the conclusion is that all software sucks?
<nh2>
so we just use the tools that are out there right now and grumble and complain until something better comes around :| (or we get the time to make something better)
<gchristensen>
no, that glaes over it too much
<gchristensen>
glazes*
<nh2>
in this area it seems to suck extra
<infinisil>
Well, all software sucks, but some suck less than others
<gchristensen>
you can sort these by how sucky they are. and remember, you're supposed to trust these things with secrets, so suckiness in different ways is huge
<infinisil>
Does suckyness build a total ordering? :P
<infinisil>
(it doesn't I know, but that doesn't matter)
<infinisil>
But yeah
<gchristensen>
all I know is I'm pretty sure I'm not capable of using GPG safely
<nh2>
special in this area that people get the *easy* bits wrong and just can't figure that out, which makes no sense and is uncommon. The hard part (the crypto) apparently usually works (I personally can't judge that)
<nh2>
like, how can the most popular *developer* crpto tool (gpg) not have an API? It escapes me
<samueldr>
make the security layer hardware, can't blame software if hardware is buggy
<infinisil>
nh2: Question regarding gpg: How are you organizing your keys/subkeys agross multiple machines?
<nh2>
but the entire environment sucks too, like recently Werner (the gpg developer) throwing the towel and saying he can't work on gpg any more because he is so poor he can't afford to live. Meanwhile 10000s of companies critically depend on gpg, including the richest in the world
<infinisil>
Oh damn
<nh2>
it got resolved eventually and people gave some money, but how can it even get into that state in the first place
<nh2>
infinisil: I have a Yubikey setup. That means a parent key, and 3 subkeys (3 split for encrypt/sign/authenticate because the Yubikey demands that). The subkeys' private keys are on the Yubikey, and require a physical keypress to do anything. The private key of the main key is on an offline machine, and to extend the subkeys, I have to retrieve it every 3 years.
<infinisil>
I see thanks, that sounds pretty good
<infinisil>
I'll consider getting a yubikey too, seems to be pretty wide-spread
<gchristensen>
they're really good
<gchristensen>
U2F is amazing
<nh2>
one can use multiple yubikeys easily, and in addition to the physical tough, one needs to enter a PIN; if one gets the PIN wrong more than 3 times in a row, the key locks up and needs to be wiped, so losing them is not a problem
<nh2>
the only drawback with the yubikeys is that the firmware was once open-source, and they closed-source the new ones for security by obscurity
<infinisil>
Huh
<infinisil>
I'll also look into alternatives I guess
<gchristensen>
nitrokeys are pretty good, but the yubikey form factor is much better
<nh2>
infinisil: I've also looked, but again it's a shit situation; in all regards beyond the open-source-ness (note, of the firmware of course, all software on the computer is open source), the yubikey is superior (for example being close to undestroyable and tamper-resistant is quite important)
<nh2>
also Google's security depends on Yubikeys, which makes them a pretty safe choice (they have some of the best people working in security, and *if* they get owned, it's likely that the bad guys will spend their efforts extracting money from Google than from you)
<infinisil>
Hehe
<infinisil>
Haven't thought of it like that
<infinisil>
nh2: But this also means that yubikeys are a big target because google is using them, soo
<gchristensen>
you're putting a lot of eggs in this basket
<gchristensen>
make sure it is a good basket
<gchristensen>
you can do that yourself, or borrow the zillions of dollars google did
<samueldr>
just made the mistake of `nix-build` outside of tmux in an ssh session... while being cd'd into a usb drive I wanted to eject
<samueldr>
(cd'd before ssh)
<gchristensen>
ouch.....
<nh2>
infinisil: yes, that's correct, but the "target" thinking here is a bit different than with other things Google is a big targer for because it's "only" the tech, not the service. For example, I think using Gmail is pretty risky in that regard because if somebody hacks Gmail, they'll likely have everyone's gmail (because the target and the service are the same here).
<nh2>
If somebody breaks Yubikeys, Tink or other stuff they make but you use on your services, you'll likely have some time before the bad guys come to you because, well, extracting Google's data takes a while (and effort)
<infinisil>
nh2: Yeah I realized that a bit after saying it
<infinisil>
I think I'll go with a Yubikey
<infinisil>
I have enough trouble with "alternate" technologies already xD
<nh2>
I do support people making alternatives though, because otherwise there will neverbe improvement over the status quo, so maybe the right thing is to buy both :D
<infinisil>
Considering that I'm pretty good at writing NixOS modules, getting an alternative key wouldn't be such a bad idea, because I could implement support for it
<nh2>
also, realistically the threat model of "somebody might hack my something-else-device more likely than my yubikey" might be silly compared to "they'll just use the publicly known Intel ME exploit that Intel decides to not patch for all devices older than 2 years, and own my whole computer"
<nh2>
(this too is "well other software is even shittier" logic)
<infinisil>
Gotta get one of those puri.sm laptops!
<nh2>
unfortunatley I have a physical addiction to Thinkpad keyboards
<nh2>
but I have a plan to solve that long term. A friend of mine is really good at making his own keyboards, and making your own hardware is getting easier by the day
<pie_>
wot <nh2> Signal has no tests and no CI
<nh2>
pie_: there were _some_ tests, but only for trivial stuff, and like 5% coverage or what
<pie_>
oh god no god why this is SO BAD I HATE IT WHEN THIS HAPPENS <nh2> recently they had "bug bankruptcy", where they just closed and locked all the bugs (1000s of them) as "spring cleaning". People protested vehemently, but they just continued
<nh2>
when I tried to make the camera flippable to the front camera in video calls, `master` didn't even compile
<pie_>
bubg bakruptcy...nice phrase#
<nh2>
there's also "pubg bankruptcy", which is also a thing
<nh2>
clever: samueldr: I finally have bisected the 10k kernel CONFIG_* options that need to added as `=y` to NixOS's kernel config so that the Chromeboot boots from SD card:
<pie_>
btw i have complaints in these veins about Tox but i think they at least get some things right (ignore the gaping holes in the walls)
<pie_>
rant rant ratn
<nh2>
the solution is pretty obvious but finding the exhaustive minimal list took the entire weekend
<nh2>
including plugging the SD card over 200 times
<pie_>
i was younger at the time so it didnt hit me but yeah nothing wrong here, nothing at all <nh2> but the entire environment sucks too, like recently Werner (the gpg developer) throwing the towel and saying he can't work on gpg any more because he is so poor he can't afford to live. Meanwhile 10000s of companies critically depend on gpg, including the richest in the world
<nh2>
clever: what I don't understand is why the NixOS initrd works on most computers. My problem is to read the initrd, I need to have e.g. EXT4=y. How does is the initrd read on normal NixOS given that all of EXT2/3/4 are `=m` in the normal NixOS config?
<pie_>
and by Tox i mean the messenger and not whatever other thing
<nh2>
clever: or is this because e.g. GRUB uses some method by which *it* puts the initrd into RAM into a specific place, before the kernel even starts, so it doesn't have to read it from a disk device?
<samueldr>
nh2: the initrd is normally put in ram by whatever bootloader, kexec included, the kernel generally is assumed to not be able to read the initrd by itself, it's the point of initrd
<nh2>
samueldr: looks like that approach will not work on the Chromebook as I have no control over the bootloader, so I will have to patch the support for these few things into the NixOS kernel
<nh2>
this also explains why kexec works but normal boot doesnot
<samueldr>
oh, I guess it makes sense, that proto-depthcharge (whatever its name is) doesn't load an initrd, right?
* samueldr
checks if depthcharge does
<samueldr>
looks like it might be able to, as part of an image built with mkimage and an appropriate .its, might be ARM specific though
<samueldr>
though... I think that `mkimage` and `.its` things might be handled by the kernel at that point...
<samueldr>
can't say for sure, no deep experience (yet?) with that stuff
<nh2>
does NixOS use initrd or initramfs? Given that clever showed me how you can unpack/pack it with cpio, that sounds like initramfs
<samueldr>
everything in nixpkgs calls it initrd... I hope everything is right
<nh2>
samueldr: everything in `nixos/modules/system/boot/stage-1-init.sh` aligns with the description of an initramfs on https://en.wikipedia.org/wiki/Initial_ramdisk (it being a shell script called /init, cpio, deletion of all files, mounting over the top). A comment inside also calls it `ramfs`. The command to load both initrd and initramfs is called `initrd` in grub
<nh2>
so we are quite likely in the "everything is wrong" case :D or they aren't really all that different to warrent different naming
<nh2>
> All 2.6 Linux kernels contain a gzipped "cpio" format archive
<nh2>
> The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image
<{^_^}>
undefined variable 'All' at (string):252:1
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):252:42
<nh2>
this suggests you can make the initramfs *part* of the kernel vmlinuz
<nh2>
samueldr: this also makes clear that what NixOS is using is definitely initramfs
<nh2>
But the remaining question is: How can I choose what goes into the initramfs that's linked into the kernel without rebuilding the NixOS kernel?
<nh2>
it would be convenient if the initramfs of the kernel were at the very end, then one could just cat it there
<clever>
nh2: grub will load both linux and the initrd into ram, and then start linux, passing it the addr of the initrd
<clever>
linux must then support the compression algo used by the initrd
<clever>
and the executable type in the initrd (elf is optional! :D )
<clever>
then it runs whatever the initrd init is
<clever>
and then its up to the distro maintainer to load compatible kernel modules, from whatever files are in the initrd
<clever>
i think most distro's just pack the world into the initrd, leading to bloat
<clever>
nixos uses nixos-generate-config to know what it needs at boot time
<nh2>
clever: on initrd vs initramfs: NixOS is using initramfs, right?
<nh2>
(as per last link I sent)
<clever>
nh2: dont remember the difference, but nixos is using a gzip'd cpio archive
<clever>
the other type, is just a whole ext4 disk image, that gets mounted via a ramdisk
<nh2>
clever: yes, the former is what the kernel docs call initramfs
<clever>
the other difference, is that with the cpio archive, the kernel will mount a tmpfs to / and extract it to that
<clever>
so you dont have to bake free space into the ramdisk
<nh2>
clever: check out that linked paragraph, it is super interesting: It says that every kernel has a little built-in empty-by-default initramfs cpio archive, and that our normal way of using it ("External initramfs images") is a special mode. There's a kconfig option to provide one to bake into the kernel image at build time
<clever>
thats if you turn on an option to bake the initrd in
<clever>
but if thats on, grub cant provide one at boot time
<clever>
the problem, is that when you have a pure build system like nix, you have to rebuild the entire kernel, when changing the contents of the initrd
<nh2>
clever: grub can still provide one at boot time:
<nh2>
`It can also be used to supplement the kernel's built-in initramfs image. The files in the external archive will overwrite any conflicting files in the built-in initramfs archive.`
<clever>
ah
<nh2>
clever: my idea: *if* that cpio archive was at the END of vmlinux (and the docs say it's exactly "134 bytes on x86" as per standard for an empty archive), then you could just replace it without having to recompile the kernel
<clever>
thats interesting
<nh2>
but the docs do not say where in the kernel it is
<clever>
658 ->>>>>>> * Try loading default modules from initramfs. This gives
<clever>
pretty sure nixos doesnt use this codepath
* clever
returns to bed
<nh2>
:D
<nh2>
clever: maybe I should build a minimal kernel with the flags I need for the Chromebook, and make a `CONFIG_INITRAMFS_SOURCE` whose `/init` simply does kexec on the root partition. It could even prompt which partition. Then NixOS or any OS would run unmodified from the root partition
<nh2>
"kexec-chainloader"
<clever>
nh2: which is the basis for my idea of putting the rollback menu into the initrd, so headless servers can still benefit from it, without grub access
<clever>
infinisil: ^^
endformationage has quit [Quit: WeeChat 2.4]
drakonis1 has quit [Quit: WeeChat 2.4]
jasongrossman has quit [Remote host closed the connection]
jasongrossman has joined #nixos-chat
__monty__ has joined #nixos-chat
jasongrossman has quit [Ping timeout: 255 seconds]
__monty__ has quit [Quit: leaving]
lopsided98 has quit [Remote host closed the connection]
<pie_>
clever, you might be the perfect person to write that book :P
<pie_>
LiNix From Scratch
<pie_>
I wish I could come up with better puns.
<infinisil>
Noice
<clever>
pie_: ive already helped a random #nixos user with the basics of just that :P
<clever>
2016-03-09 06:13:24 < Darksecond> clever: I'm a bit silly and like to do a LFS style build with nix as the package manager (to get a better understanding about nix)
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 255 seconds]
Church- has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 258 seconds]
endformationage has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis2 has joined #nixos-chat
drakonis has quit [Ping timeout: 257 seconds]
drakonis2 has quit [Client Quit]
drakonis1 is now known as drakonis
drakonis_ has quit [Ping timeout: 252 seconds]
endformationage has quit [Quit: WeeChat 2.4]
jtojnar has joined #nixos-chat
jtojnar has quit [Client Quit]
kisik21 has joined #nixos-chat
jasongrossman has joined #nixos-chat
jasongrossman has quit [Client Quit]
endformationage has joined #nixos-chat
jasongrossman has joined #nixos-chat
endformationage has quit [Quit: WeeChat 2.4]
endformationage has joined #nixos-chat
kisik21 has quit [Read error: Connection reset by peer]
<ivan>
TIL I have to patch prometheus_2 to get correct numbers out of the rate/delta/increase functions
<ivan>
the results are visibly different without the weird interpolation
<ivan>
I guess the more important difference is that the functions that Prometheus has don't include the last point before the range
<ivan>
(the series disappears if the range becomes small enough)
<simpson>
Hilarious.
<nh2>
clever: OK I now have a nice tarball I can generate to put on the root partition forthe Chromebook, with a slightly patched kernel (but within the nix expression that builds the kernel, so that's fine for now). Now I want to make sure nix works well when invoked on that machine; the things you already showed me already seem to work.
<nh2>
Do you know whether I should make `nixos-generate-config` run somehow, and how I can make that the stable channel is selected?
<clever>
nh2: the output should be stable for that hardware, so you can bake its results into your thing
__monty__ has joined #nixos-chat
drakonis has joined #nixos-chat
<infinisil>
One time I talked with some random chinese dude at my university
<infinisil>
He just started talking to me really
<infinisil>
I had my laptop open, had NixOS running, he asked me some things about it
<infinisil>
He mentioned that he uses Scientific Linux, because it's very solid and professional or something
<MichaelRaskin>
They have been working on providing a migration to CentOS + EPEL with the same effort as normal major-version upgrade, apparently
<MichaelRaskin>
Now they decided the result is good enough
<infinisil>
I see
<drakonis>
what makes scientific linux different from centos?
<drakonis>
rather, where does it differ
<__monty__>
Probably not much now but maybe it did when CERN wasn't using CentOS yet?
<__monty__>
I'd assume it'd just come with more scientic libraries packaged.
<pie_>
infinisil, oh shit :P
<drakonis>
it doesnt come with more scientific libraries packaged
<pie_>
infinisil, i watched nixcon the talk from that one CERN guy yesterday
<drakonis>
apparently it provides a better base for scientific research
<__monty__>
That says nothing.
<drakonis>
they have the same package set as rhel/centos
<MichaelRaskin>
This might have been the recent result of the preparation to discontinue SL, though
<__monty__>
And the decision to discontinue could already have been the result of the distinction shrinking. You need to look back to the older releases and the same age for CentOS.
<drakonis>
the amount of scientific packages on centos and fedora had steadily increased
<pie_>
i want to start packaging science stuff for nix at some point but i have too much on my plate already :(
<pie_>
im trying to figure out how this could be turned into some kind of horribly cursed filesystem based REPL or something with nix but i cant think of anything