<clever>
Heffalump: fixed-output derivations can use any hash, md5, sha1, sha256, sha512, md5 is already being phased out, and sha1 can easily be removed as well
<clever>
yeah
<clever>
Heffalump: ive heard something about the attack working by appending large amounts of specialy crafted junk, which changes the size in that header, causing the state of the sha to become scrambled
<clever>
which destroys any pre-existing collisions
<clever>
git does its object storage and de-dup after prefixing the files with the above mentioned header
<clever>
Havvy: i believe they used svn
<clever>
tilpner, Havvy: but of note with git, all files have a header of "blob %d\0" prepended to them, including the size of the data
<clever>
maybe 512
<clever>
Havvy: nix will package the entire directory tree up as a NAR, then hash that with sha256 i think
<clever>
Havvy: i think the bigger issue is going to be the git nixpkgs is stored on
2017-02-26
<clever>
sphalerite: blanking out the start of the drive silences all warnings, so they wont ask you to confirm things
<clever>
sphalerite: some tools like mkfs.ext4 will warn you that your trying to format an existing filesystem
<clever>
that kind of thing can be hard to debug, because the debug tools are also broken
<clever>
ekleog: which the vm will import on bootup, to convince nix that the things in /nix/store are valid
<clever>
ekleog: the reginfo file is just a partial dump of nix's db.sqlite
<clever>
mount --bind is similar to a hardlink
<clever>
ekleog: the sandboxes for nix builds work in a similar way
<clever>
ekleog: if you have root on the host, you could use mount --bind to copy parts of the store to an area like /tmp/vm1/nix/store/ and then expose that
<clever>
ekleog: this allows the guest to mount the host /nix/store without having to use any block devices or filesystems
<clever>
sphalerite: this netboot.nix lets you build the netboot images from any configuration.nix you want, so you can freely configure whatever you want
<clever>
sphalerite: you add a binary cache to its nix.conf via the same gist, and nix-serve can act as a binary cache
<clever>
sphalerite: if you customize the nixos in the netboot using the gist i linked, you could even add xfce to it, if you where feeling crazy enough
<clever>
sphalerite: :D
<clever>
i think the only way to unfork it, would be to delete the entire project (and all issues/pr's), then remake it as a not-fork, and upload
<clever>
and the fork is now the active branch of the project and has the changes i want
<clever>
i sometimes have to clone a repo to grep it, because github refuses to search a fork
<clever>
Unode: i just grep a nixpkgs checkout
<clever>
a gimp plugin
<clever>
pkgs/applications/graphics/gimp/plugins/default.nix: name = "wavelet-sharpen-0.1.2";
<clever>
and that has nothing to do with hydra
<clever>
about all i can think of then is that the binary cache didnt respond in time
<clever>
do you have any packageOverrides in your config?
<clever>
that channel will only update once hydra has tried to build every single job
<clever>
Unode: which channel are you on and what is compiling?
<clever>
ah, nice
<clever>
gchristensen: how did you activate hibernation?, gui or cli?
<clever>
in the middle of me using a voice chat program
<clever>
i had closed the lid because it was in the way, and it went into standby on its own
<clever>
gchristensen: and i wound up testing standby by mistake already, lol
<clever>
gchristensen: that reminds me, i havent tested hibernate at all on my laptop
<clever>
sphalerite: you can also test a lot of this out under VM's, qemu lets you execute a kernel+initrd pair easily, and virtualbox can record the screen to video
<clever>
LnL: and sanboot just hooks the drive, then executes sector 0, triggering the normal boot process
<clever>
LnL: in theory, this might even work for dos and windows 3.11
<clever>
LnL: so any OS that uses the bios to read the hdd, will go over iscsi
<clever>
LnL: ipxe will hijack the legacy hdd API in the bios, and reroute hdd access to iscsi
<clever>
LnL: yeah
<clever>
sphalerite: i used the kexec method on both of those
<clever>
sphalerite: 2 so far
<clever>
sphalerite: i have had to convert a few ubuntu servers to nixos, without any physical access to the machines
<clever>
lol
<clever>
viric: but its currently not in use right now
<clever>
viric: i have used it to netboot nixos on my laptop before, even the MBR for grub was on the iscsi drive
<clever>
sphalerite: and there is no way for the anti-virus to detect it from within the vm
<clever>
sphalerite: this also has security implications, in theory, i could put a hypervisor into the NIC boot rom, that then boots the hdd under a vm
<clever>
sphalerite: probably more likely to have it omited, but you can sometimes just stick a crappy 100mbit card onto the pci bus, purely for the bootrom
<clever>
so you can reflash it with a utility that knows the NIC
<clever>
most of the time, its actualy flash memory
<clever>
3 would require coreboot support, which is harder to find
<clever>
2 should be possible with anything that has an ethernet card
<clever>
some motherboards have ISP, but its not always documented
<clever>
either pull it out of the socket or de-solder it
<clever>
in the case of 3, you need to rip the bios chip off the board and reflash it, if you want to bypass the signing requirements
<clever>
3, as a payload in coreboot, directly in the bios
<clever>
2, directly into the boot rom of a NIC
<clever>
1, put it into the hdd via grub
<clever>
3 main options i was thinking of
<clever>
and even if somebody does get into the network, they cant inject custom code
<clever>
sphalerite: the design idea behind that boot method, is that you cant brick the hardware, you can always swap files out on the tftp server, hard-reset the machine, and it will come back to life
<clever>
i use that any time i need an example that will be publicly visible
<clever>
yep
<clever>
sphalerite: so you can just make your own self-signed cert, and use that key to sign things
<clever>
sphalerite: a certificate is embeded into ipxe at build-time
<clever>
sphalerite: this one compiles down to a ~47mb squashfs (1/4th the size of the netboot image), and all files it executes must be signed with a certificate
<clever>
sphalerite: and because that netboot kernel+initrd runs nixos entirely from ram, i have also thrown them at kexec
<clever>
and you can obviously customize that to match the partition layout you want, and fs types
<clever>
sphalerite: oh, and line 11 of justdoit, i believe if you remove the size= field, it will just take the entire disk automaticaly
<clever>
it still needs some nixos modules to add iscsi support to the initrd after that step
<clever>
that only gets you far enough to load the kernel+initrd
<clever>
sphalerite: due to how sanboot works, grub thinks its booting from a normal hdd in the local box, but ipxe is redirecting it over iscsi transparently
<clever>
sphalerite: line 6 of boot.php is another fun test i did, that laptop was booting with the rootfs and grub on iscsi
<clever>
Unode: and you need to fix the uuid for / in either hardware-configuration.nix or configuration.nix, so it can find the new root
<clever>
Unode: you need to fix the boot.grub.device in configuration.nix, so it knows what to grub-install against
<clever>
sphalerite: the ipxe embeded into virtualbox doesnt handle http, so i have to chainload a better ipxe, and then detect the difference
<clever>
sphalerite: oh, and the version thing on line 12 is just to work around weirdness in virtualbox
<clever>
sphalerite: and boot.php is something i have to allow each machine to boot into a different image, so i can dynamicaly configure things without having to touch the dhcp server
<clever>
sphalerite: gistfile1.txt is how the modified netboot gets built
<clever>
and it needs to enable ssh and setup an ssh key so you can get in
<clever>
target-config.nix will need to exist when you build that configuration.nix to make the netboot image
<clever>
so you can just type "justdoit" into the root shell, and it does it
<clever>
sphalerite: this is fragments of some config from an example i made 3 months ago, it modifies the netboot image to include a script called justdoit
<clever>
sphalerite: that will generate a directory containing an ipxe script, along with a kernel+initrd, and if you boot those, you get the same env as if you had booted from a cdrom
<clever>
sphalerite: the nix-build command is in the youtube description
<clever>
but i do try avoiding entering anything secret on the site anyways
<clever>
greymalkin: i also check it, but my browser doesnt remember the exception for that long, and i sometimes skip checking the next time it comes up
<clever>
and if it already has ssl warnings, is anybody going to notice a self-signed cert?......
<clever>
greymalkin: and judging by what i saw in tcpdump when debuging network issues, i suspect i can mitm any box in the datacenter, potentialy including the main website
<clever>
greymalkin: the main website for a datacenter i use, has an ssl cert that expires 130 days ago
<clever>
xcmw: is there anything near the end relating to illegal instructions?
<clever>
xcmw: is dmesg a valid command, what happens when you try to run it?
<clever>
xcmw: does osx have anything like dmesg, which may say which process exactly is failing?
<clever>
1.11.6 is using an external program to check signatures on nar files!
<clever>
that code has changed massively
<clever>
things may be different in nix master
<clever>
copumpkin: and further reading shows that with nix 1.11.6, there doesnt appear to be a way to --import into a store mounted at the "wrong" location, you will need to keep fakerooting for now
<clever>
copumpkin: you could maybe use nix-store --register-validity and NIX_STATE_DIR to alter db.sqlite, after having rsync (or --restore'd) something in, i'll read some more related source...
<clever>
yeah
<clever>
copumpkin: so this variable is to modify a store that will always be at a weird place, not one that is temporarily at a weird place and will become /nix/store later
<clever>
copumpkin: and its expecting the --export to contain absolute paths, starting with /tmp/mnt/nix/store, that where compiled against that path
<clever>
copumpkin: because of NIX_STORE_DIR, nix believes the store will be at /tmp/mnt/nix/store, at runtime!
<clever>
copumpkin: oh wait, i think i see the problem
<clever>
NIX_STORE_DIR=/tmp/mnt/nix/store ... error: path ‘/nix/store/kk71vkqipf30qc165718jmp0s8cggn2y-glibc-2.24’ is not in the Nix store
<clever>
copumpkin: aha, its complaining that /tmp/mnt/nix/store isnt a sub-dir of /nix/store
<clever>
copumpkin: aha, the 1.11.6 source of nix is fairly different in this region
<clever>
it will be much much much harder to collide 2 or 3 hashes at once
<clever>
shlevy: it appears to be using sha256, sha512, and whirlpool, for all of its "fixed-output style" downloads
<clever>
shlevy: the approach ive seen in gentoo, is to put several hashes on the object at once
<clever>
shlevy: if something in nix gets compiled to take advantage of that opcode, it will just not run at all on other cpu's, and now the binary cache needs 2 copies of every build
<clever>
copumpkin: i still need to figure out why this doesnt work!, lol
<clever>
copumpkin: looks like i'll need to build nix to debug this further
<clever>
ive been using sha256 and 512 on things since 2 years ago
<clever>
shlevy: i hear there are ways to check files to see if they have signs of being used for a collision, but those signatures may change in the future
<clever>
shlevy: pretty much
<clever>
viric: same reason all modern servers reject ssl 3.0 connections, you can perform a downgrade attack via mitm, before either end has been verified with certs
<clever>
viric: enless you keep the old sha1 hashes for backwards compat, and then somebody can just insert a sha1 object and exploit away
<clever>
viric: in theory, you could, but it would invalidate every git commit hash out there, and also invalidate all of the existing signatures in the git history
<clever>
viric: yeah
<clever>
viric: you would have to re-clone the entire project, and compare every blob in the history
<clever>
viric: yeah, in that event, they can swap things out, and you cant notice by doing a git pull
<clever>
so it should stick to whatever version it got first
<clever>
and similarly, github shouldnt accept a new version of an object being uploaded
<clever>
viric: so an old git clone and a new git clone can produce 2 different trees for the exact same commit
<clever>
viric: but anybody who already downloaded that version wont re-download it, because git assumes that if the sha1 matches, it already has a copy
<clever>
viric: yeah, if you can collide one file in the tree, then you can swap out its contents in every commit that references that exact version of the file
<clever>
viric: to keep the chain of commit hashes intact, and to subvert the signatures, you need to hash collide against the sha1 of the commit
<clever>
this is also something i noticed that gentoo did differently, every file portage can download has 3 hashes on it, a sha256, a sha512, and a Whirlpool hash
<clever>
viric: but in all of those cases, it has the same sha1 as its ID, so the local git client will think its the original you had to begin with, and wont download the modified one
<clever>
viric: it could be anything from a modified commit, directory, or file
<clever>
viric: so you can only see it on the web ui, or with a fresh git clone
<clever>
viric: yeah, if github was somehow hacked, you would have a hard time noticing this issue, because your own git client wont re-download the modified blob
<clever>
viric: but the same applies to github, you cant upload a blob that github already has in the project, so i cant see it being abused easily
<clever>
viric: so if an attacker replaces an object on the remote git server, your git client wont download it, because you already have an "identical file" on your machine
<clever>
viric: one thing i can see as making the sha1 stuff harder to exploit, "git pull/fetch" wont re-download an object you already have
<clever>
copumpkin: so if i run nix-store --import and set the right vars, i can see it unpacking to /tmp/mnt/nix/store/nix-22852-0/unpacked, but it then fails to move it to the store for unspecified reasons
<clever>
suolrihm: and if you look in /dev/usb/, what are the permissions and user/group of the node for that usb device?
<clever>
suolrihm: and your in the wheel group on this new machine?
<clever>
suolrihm: can you pastebin that nix file?
<clever>
suolrihm: the simple fix is to just find its bus and device number in lsusb, then give yourself read permissions to its entry under /dev/bus/usb/, though that will have to be repeated each time you plug it in or reboot
<clever>
suolrihm: udev rules would automate fixing the permissions every time it gets plugged in
<clever>
suolrihm: but i no longer have access to it, and forgot to make any PR's
<clever>
suolrihm: i had a chance to mess with it a bit, i had to chmod the usb dev node under /dev/bus/usb/ so the user has r/w perms
<clever>
k0001: revCount is the total number of commits i believe, and outPath allows you to treat that nixpkgs attrset as a normal path
<clever>
k0001: so if your release.nix has { nixpkgs }:, you can get the revision at nixpkgs.shortRev
<clever>
k0001: every input you list in hydra is passed to the main nix file you set in the jobset config, as an attribute set like this