<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 _2_4 25  
26 27 28 29 30 31
00:03 transhuman_ joined
00:04 <transhuman_> hi I am trying to integrate msmtp with alpine-linux and wordpress who should own the configuration file should it be apache www-data or root and if so what permissions?
00:46 slowpak joined
00:59 atomi_ joined
01:03 ahrs joined
01:11 fekepp joined
01:16 czart__ joined
01:19 hackerhercules joined
01:35 grayhemp_ joined
01:40 white_knight joined
02:36 Janhouse joined
02:48 s33se_ joined
03:19 sagebind joined
03:23 IRCFrEAK joined
03:36 blueness joined
03:57 aw1 joined
04:04 mguentner joined
04:06 asie joined
04:11 BitL0G1c joined
04:13 nasonfish joined
04:21 cyborg-one joined
04:21 blackwind_123 joined
04:31 IRCFrEAK joined
04:39 mguentner2 joined
05:05 jzono1 joined
05:26 grayhemp joined
05:45 minimalism joined
05:46 grayhemp joined
05:54 grayhemp joined
06:10 grayhemp joined
06:14 grayhemp joined
06:16 aw1 joined
06:19 grayhemp joined
06:23 grayhemp joined
06:26 FRP-admin joined
06:35 fragtastic joined
06:36 grayhemp joined
06:37 ahrs joined
06:38 grayhemp joined
06:45 luxio joined
06:47 grayhemp joined
06:55 grayhemp joined
06:58 grayhemp joined
07:06 aw1 joined
07:13 grayhemp joined
07:17 gogoprog joined
07:26 grayhemp joined
07:27 nanohest joined
07:38 grayhemp joined
07:47 grayhemp joined
07:47 avih joined
07:52 grayhemp joined
08:01 grayhemp joined
08:03 grayhemp joined
08:10 grayhemp joined
08:21 grayhemp joined
08:30 blueness joined
08:34 BitL0G1c joined
08:40 grayhemp joined
08:42 xsteadfastx joined
08:43 grayhemp_ joined
08:44 t0mmy joined
08:49 xsteadfastx joined
08:54 atmoz joined
09:03 dent_irc joined
09:09 t0mmy joined
09:33 grayhemp joined
09:34 lesion joined
09:36 stwa joined
09:46 dent_irc joined
09:50 royger joined
10:16 rrx joined
10:32 <TBB> okay, I'm a couple of months late but I'm now basically preparing that single-file secure boot kernel thing I talked about
10:33 <TBB> so I wanted to have opinions on where people prefer to keep their signing keys for that thing... options at this point are either a security token, the file system or possibly some GPG hack
10:35 <TBB> keeping them unencrypted in the filesystem is probably a very bad idea
10:35 grayhemp joined
10:44 dent_irc joined
10:46 <^7heo> I want to get some physical device
10:46 <^7heo> that has two operation modes
10:46 <^7heo> 1. sign blob
10:46 <^7heo> 2. decrypt blob
10:47 <^7heo> and I want that device to only expose the public key
10:47 <^7heo> so basically
10:47 <^7heo> you have a private key
10:47 <^7heo> IN the device
10:47 <^7heo> generated ONCE
10:47 <^7heo> and it can not leak, it can only be used WITH the device.
10:48 <^7heo> the problem is that this device will have a limit of the size of what it can sign/decrypt
10:49 <TBB> true, which is why you usually don't use for decryption, mostly just verifying signed hashes (if I understand correctly)
10:49 <^7heo> anything else is pointless imho.
10:49 <^7heo> nah
10:49 <^7heo> you use the public key for both checking the signatures and encrypting.
10:49 <TBB> there's one little problem with the strategy you suggested though, even though it is sensible
10:49 <^7heo> you use the private key for both signing and decrypting.
10:50 <TBB> being, if you generate the keys inside a security token and do it properly, in other words so that you can't get the private key written out, then that token becomes a single point of failure
10:50 <^7heo> yeah exactly.
10:50 <^7heo> that's by design.
10:51 <^7heo> the token in question needs actually 4 features, and exactly 4.
10:52 <^7heo> the two I quoted, the one thing I said as "not a feature" which is exposing the public key
10:52 <^7heo> and another one: exporting the revokation certificate once.
10:52 <^7heo> it's up to you to store it properly.
10:53 <TBB> mhm, makes sense
10:53 <^7heo> ideally
10:53 <^7heo> there would be 2 tokens
10:53 <^7heo> physical ones
10:53 <^7heo> the one I'm telling about
10:53 <^7heo> and the other one being a write-once revocation-storage
10:54 <^7heo> that you can plug the other token into
10:54 <^7heo> so to generate that revocation storage once and for all.
10:55 <^7heo> so yeha
10:55 <^7heo> yeah*
10:55 <^7heo> that's a device I want.
10:57 grayhemp joined
11:12 t0mmy joined
11:12 <hiro> you guys are going over the top there
11:13 <hiro> you're optimizing one security detail
11:13 <hiro> but it's not the common source of breach
11:13 <hiro> you will want to run your computer mostly in a booted state, and the real secrets will probably be loaded in ram
11:14 <hiro> all you can do is not put it on the internet directly
11:14 <hiro> and physically secure the site (i'm sure you haven't done that :P)
11:24 dent_irc joined
11:37 <^7heo> hiro: yeah but it's not because we can't secure A that we shouldn't secure B.
11:38 <^7heo> sure it won't improve the security for now.
11:38 <^7heo> but it will not hurt.
11:41 <hiro> time is limited
11:41 <hiro> that's how it hurts
11:42 <hiro> if you do things that have no concretely useful effect you're wasting time better spent on actually useful things
11:42 <hiro> also it gives everybody around you a wrong sense of importance
11:43 <hiro> while they might not choose to be distracted by such topics if they aren't even worth it
11:43 <hiro> and it's not like you're working on one closed, controled system that wil gradually improve, and if not in your lifetime then generations later
11:44 <hiro> this whole IT bullshit is extremely volatile and there's barely any iterative progress in the last 10 years
11:46 <hiro> so it has to work and be useful now, or it will never happen.
11:47 blueness joined
11:55 <^7heo> I agree with you that it's easier to secure that than secure the RAM of the computers.
11:56 <^7heo> however I want to secure that, we're enough humans that other people would figure out the rest.
11:58 <TBB> I don't see the problem you describe, hiro, in implementing Secure Boot and managing the keys for it. and naturally it is not the only component providing security. in my use case at least this is a perfectly justifiable thing to do.
12:06 <hiro> well, it's a waste of time, and in my opinion
12:06 <hiro> your's will naturally differ :)
12:06 grayhemp joined
12:07 <hiro> i don't believe in this way of labour division
12:07 <TBB> let's just say that my use case is untypical
12:07 <hiro> i don't think anything will work out in the long-term without better priorization
12:08 <hiro> TBB: ok. it sounded like you were gonna build a generic solution at first.
12:09 <TBB> I'm sort of doing that too; the methods for doing Secure Boot are well known but they're not necessarily widely packaged into tool form, and one of the reasons is the question of key management, I guess
12:10 mitemite joined
12:11 lesion joined
12:15 <hiro> i have an encrypted home dir
12:15 <hiro> i don't get what people pretend to gain from further fuckery
12:15 <hiro> in my experience it just makes administration a pain most of all
12:16 <hiro> and for like security level 2 i just have a *seperate* rarely mounted partition
12:17 slowpak joined
12:19 gromero joined
12:21 <IcePic> FDE is so mom wont find your stash of unicorn anime movies. =)
12:24 <hiro> no, just bec. of work shit
12:25 <hiro> fde is useless
12:25 Kruppt joined
12:26 <hiro> the real test is: do you turn off your laptop when you travel
12:26 <hiro> if you don't then fde is not just useless but also laughable.
12:27 <hiro> and worse than my unmounted partition while my computer is in suspend
12:27 <hiro> less user friendly and at the same time less secure... why!
12:31 kunev joined
12:34 <darkfader> hiro: argh
12:34 <darkfader> you act as if it's binary and no other factors apply
12:34 <darkfader> IF i travel to a questional country or have specific data they might want
12:35 <darkfader> THEN I'll turn it off during the travel
12:35 farosas joined
12:35 <darkfader> IF it gets stolen by randoms in *any* (on or off) state, FDE is enough
12:35 <darkfader> IF I don't go to a hostile place, encryption doesn't HURT me
12:36 <darkfader> BUT I can't suddenly turn an unencrypted device into an encrypted one, so it needs to be IN PLACE
12:36 <darkfader> it's just 5 years since I needed to FDE a whole team's laptops a week before going to the airport
12:37 <darkfader> back then there was no cpu offload and FDE drives (too) were hard to get
12:37 <darkfader> but it was likely that the dest country we worked for might just wanna have those sources... so
12:38 <darkfader> (non military stuff but that isn't enough to be left alone)
12:39 <darkfader> i got secure boot on the mostly-useless list for devices you keep around
12:39 <darkfader> phone base stations etc. all need it (they used trusted grub years ago)
12:41 <TBB> I don't know how useless it is really. when you harden a laptop you block booting from external sources, so one attack is to change the kernel and/or the initramfs. secure boot mitigates that somewhat, although arguably you can always just reset the firmware
12:47 lesion_ joined
12:48 <TBB> but since I'm a big believer in layered security... why not
12:51 <darkfader> TBB: ack, i suppose if i play with TPM at some point i'll make more use of all that
12:56 lesion__ joined
13:21 <hiro> 13:36 darkf BUT I can't suddenly turn an unencrypted device into an encrypted one, so it needs to be IN PLACE
13:21 <hiro> granted
13:22 nanohest_ joined
13:23 <hiro> it's the first good argument for encrypting non-important data i've heard, but it does convince me immediately :)
13:23 <hiro> i do know it is a fucking hassle to change from an encrypted drive to a non-encrypted.
13:24 <hiro> so yes, the opposite should be the same.
13:24 <hiro> i'm a big believer in trying to keep the layers down to the bare minimum possible.
13:24 <hiro> because of complexity
13:25 <hiro> plainly i'm not clever enough to understand too many complex layers.
13:30 atmoz joined
13:31 nanohest joined
13:37 grayhemp joined
13:39 dfs joined
13:54 nanohest joined
13:57 nanohest joined
14:20 <darkfader> hiro: your "secure stage" mount is a super practical thing
14:21 <darkfader> i like file-backed most for that because then i can make sure my backup only includes the encrypted thing and not the mounted versiob
14:21 <darkfader> which is the big fallacy with FDE in my case
14:21 t0mmy joined
14:22 <darkfader> unless i start encrypting my backup server and having a smart card to unlock a restore
14:22 <darkfader> which would be totally fine if i had nothing else do in my life :(
14:27 <^7heo> < hiro> it's the first good argument for encrypting non-important data i've heard, but it does convince me immediately :)
14:28 <^7heo> I thought it was self-explanatory
14:28 <hiro> there are many wrong arguments claimed all the time about this topic
14:28 <hiro> i often have conversations with non-tech people who ask me why i don't use fde
14:29 <hiro> cause *sadly* they found out it exists and wasting their time with it now...
14:29 <hiro> can't even help them back up their systems any more :D
14:29 <hiro> or recover their deleted files.
14:29 <darkfader> i think with a very structured OS like Nix you couldn't even make that argument because then it'd be "copy data, flip two lines of system config, copy back"
14:29 <darkfader> but for the non-cool OS, it's a f**** hassle
14:30 <hiro> darkfader: with file-baacked you mean you mount raw images?
14:30 <darkfader> hiro: yeah, where you loop-mount them or so
14:30 <darkfader> or truecrype when it was still around
14:30 <darkfader> ah, typos ftw. i'll go have lunch :)
14:30 <hiro> i am *having* lunch right now :D
14:31 <hiro> lots of rice on the keyboard, no excuse
14:31 <hiro> i was thinking of using qcow2, but you can't directly mount them without that qemu nbd stuff, and it makes me wonder how stable it will be...
14:32 <hiro> it's just not common enough for me to feel like i should trust it for *important* data.
14:32 <hiro> but for backups i should probably move from a partition to a sparse img like you propose.
14:33 <hiro> if only sparse images were better supported by rsync and the like!
14:33 <hiro> it's all very ugly to use.
14:39 nanohest joined
14:41 nanohest joined
14:42 subscope joined
14:43 zgrepc left
14:44 Skele joined
15:06 grayhemp joined
15:09 aw1 joined
15:09 blueness joined
15:11 aw1 joined
15:13 fabled joined
15:16 Kruppt joined
15:24 <transhuman_> anyone know of any hosting providers that offer alpine-linux as an option?
15:24 <transhuman_> looking at linode and digitalocean it doesnt appear they support it
15:25 <transhuman_> bb soon to see replies
15:27 <transhuman_> thanks in advance
15:31 <scadu> transhuman_: scaleway
15:32 TheXzoro1 joined
15:34 <^7heo> transhuman_: vultr allow to use any iso to setup your syste,
15:34 <^7heo> system
15:49 <Death_Syn> vultr actually has the alpine 64-bit iso included in their ISO library now
15:49 <Death_Syn> though you can still add your own version if you like
15:52 <dalias> :-)
15:52 <dalias> do they show hashes on the ones in their library?
15:53 <dalias> obviously you can't check it yourself but it would be nice to know they claim it's the same as the official one
15:53 dlaube joined
15:53 <dalias> i usually don't trust hosting providers to be providing the unmodified distros
15:54 <dalias> because they often have wacky stuff like scripts to import ssh keys from the hosting panel and other things that could impact security or functionality
16:02 grayhemp joined
16:05 <^7heo> some however clearly indicate that if you don't run the standard ones they built
16:05 <^7heo> you'll have no support for integration
16:09 Spydemon joined
16:11 grayhemp joined
16:14 Kruppt joined
16:23 <hiro> transhuman_: i recommend ramnode's kvm option
16:25 aw1 joined
16:27 atmoz joined
16:31 <transhuman_> thanks hiro
16:51 lesion joined
16:51 grayhemp joined
16:51 hackerhercules joined
17:00 hackerhercules joined
17:02 Nobabs27 joined
17:10 subscope joined
17:12 grayhemp joined
17:13 grayhemp joined
17:19 wonton joined
17:24 gopar joined
17:32 grayhemp_ joined
17:34 wonton joined
17:40 <transhuman_> thanks scadu ^7heo
17:41 <scadu> transhuman_: scaleway seems to be pretty transparent. see their github.
17:45 grayhemp joined
17:49 grayhemp joined
17:51 blueness_ joined
17:55 grayhemp joined
18:00 dent_irc joined
18:10 Berra joined
18:11 nanohest joined
18:17 grayhemp joined
18:32 <transhuman_> scadu: thanks and question for you it says flexible ipv4 address is that another way of saying dynamic?
18:34 <scadu> transhuman_: from their site: "To reinstall your server, simply delete your existing server. When you delete your server, your flexible IP address is kept in your account and you can spawn a new server with the same IP address."
18:35 <scadu> transhuman_: not sure if the answer satisfies you.
18:36 <transhuman_> well, it doesn't answer the question but I guess if it never changes then it would be a static IP address in function rather than by whatever internet organization would refer to as static
18:36 <transhuman_> good enough thanks
18:48 dent_irc joined
18:52 atmoz joined
19:00 grayhemp joined
19:03 xming joined
19:03 xming joined
19:04 grayhemp joined
19:05 ahills joined
19:06 <ahills> is there a way to increase the size of the ramdisk allocated for / so I can install more packages?
19:07 grayhemp joined
19:09 <ahills> looking at /usr/share/mkinitfs/initramfs-init, maybe it's root_size
19:09 <ahills> or rootflags=size=...
19:11 <ahills> I wonder where the default size is defined...
19:12 <dalias> ahills, why do you assume it's limited size?
19:12 <dalias> normally tmpfs is unlimited unless you provide a limit
19:12 <ahills> dalias: because I run out of space trying to install packages :)
19:12 <ahills> so, you mean it's hitting a RAM limit?
19:13 <dalias> not sure
19:13 <TemptorSent> ahills: do a df and a free and see what you have.
19:14 <TemptorSent> I hit that spinning up a vm.
19:14 <ahills> TemptorSent: Mem: 998 742 255 (total/used/free MiB), df shows 499.0M 457.2M 41.9M 92% /
19:14 <ahills> so, as per man 5 tmpfs, it's set to half available RAM
19:15 xsteadfastx joined
19:15 <ahills> dalias: should the tmpfs at / be growing?
19:15 TemptorSent joined
19:16 <ahills> oh I see, you can only specify an upper limit
19:16 <dalias> tmpfs doesn't have a fixed size
19:16 <dalias> this is not 1995 with ramdisk block devices
19:16 TemptorSent joined
19:17 <dalias> tmpfs is just normal vfs with no on-disk-fs backing behind it
19:17 <ahills> I did not have ramdisk block devices in 1995
19:17 <dalias> :)
19:17 <TemptorSent> Sorry about that, found an illegal instruction somehow?
19:17 <dalias> i mean it's not the design from decades ago
19:17 <TemptorSent> tmpfs will back to swap IIRC?
19:17 <dalias> yeah it can get swapped out
19:18 <ahills> having now read /usr/share/mkinitfs/initramfs-init and tmpfs(5), I think I have my answer
19:18 <ahills> time to try it
19:18 <dalias> i don't think the initramfs is relevant
19:18 <TemptorSent> ahills: Yeah, working on rewriting initramfs-init as we speak.
19:18 <dalias> is not the initramfs
19:18 <dalias> is it?
19:18 <dalias> i thought a new tmpfs was mounted after the initramfs phase of booting
19:18 <TemptorSent> dalias: Yes, that's what sets up the tmpfs
19:18 <ahills> dalias: no, I read that to figure out if there's a way to specify the size of the tmpfs, found out that I can specify the upper limit, and increase it beyond the default of half available RAM
19:19 <TemptorSent> dalias: It will take options from the sysroot/etc/fstab
19:19 <ahills> or, in the case of this system, it will take them from the kernel command line
19:19 <TemptorSent> ahills: Yes, you can specify the rootflags=size=$size
19:20 <TemptorSent> I'm about to remove the obsolete root_size option.
19:20 <ahills> which wiki document would this most belong in?
19:20 <ahills> I'll add it in a minute
19:21 <ahills> I spent too long searching for this before remembering alpine source code is easy to read
19:21 <TemptorSent> ahills: Good question -- I haven't even tried to figure out where it is currently documented.
19:21 <ahills> it is not
19:21 <ahills> is the answer
19:21 <TemptorSent> ahills: mkinitfs-init is easy to read?
19:21 <ahills> well, unless you count source as documentation
19:21 <ahills> right
19:21 <ahills> well, I think it is... alpine scripts are where I learned to write well-formed sh
19:22 <TemptorSent> ahills: Are you up to help with documenting the new mkimage/mkinitfs system by chance?
19:23 <ahills> TemptorSent: maybe? is it live already?
19:24 <TemptorSent> ahills: There is now a rather more complete profile system as well as modular feature system for the fs.
19:24 <ahills> nice!
19:24 <ahills> well, I'm just about to install alpine on another laptop, so now's a good time to use it
19:24 <TemptorSent> ahills: Not quite live yet, my work branch (which will end up in its own repo) is at https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
19:26 <ahills> TemptorSent: does it work?
19:26 <TemptorSent> ahills: Please take a poke at it and let me know what breaks. The minimum to pass it is --profile and one of the repo options ( --repository-file /etc/apk/repositories works )
19:27 <TemptorSent> ahills: I've been testing mostly using the virt image in qemu, and unless I fubard somethign recently, it was building and running successfully.
19:27 chris| joined
19:27 <ahills> why is github making it difficult to see the diff...
19:28 <TemptorSent> ahills: It also should be able to cross-build to other platforms, but I currently can't test it on my system because of a bug in apk that causes it to puke.
19:28 <TemptorSent> ahills: Dunno, although there's not much of the original left to see :)
19:29 <ahills> fair enough
19:29 <TemptorSent> You should be able to do the 'compare' and see the history.
19:32 <TemptorSent> ahills: mkinitfs has been encapsulated in initfs/plugin-mkinitfs.sh
19:34 <TemptorSent> ahills: The actual implementation was largely retained, but the whole of the outer logic was axed and a compatibility wrapper added.
19:36 <TemptorSent> ahills: That is where the integration with the new init will be added, probably using the same code as the files/modules do now and apks will soon.
19:36 <TemptorSent> ahills: The rest of it should be pretty well documented :)
19:37 orbiter joined
19:45 <TemptorSent> ahills: If any names / options need to be changed, now is the time to do it, not after the 3.6 release.
19:47 <TemptorSent> ahills: I skeld out the docs needed in the TODO, I just haven't had time to start writing them yet, I want to get feature-complete and tested worse than I want to get nicely documented at the immediate moment.
19:49 <TemptorSent> Anyway, I'm heading out for the day in a little bit, so let me know what you find and I'll attack it when I get back.
19:52 <ahills> TemptorSent: will do
19:56 nanohest joined