1477958737 Q * Romster Ping timeout: 480 seconds
1477958764 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1477959757 Q * Romster Ping timeout: 480 seconds
1477961257 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1477964071 J * fstd_ ~fstd@x4e30e4b7.dyn.telefonica.de
1477964525 Q * fstd Ping timeout: 480 seconds
1477964525 N * fstd_ fstd
1477966960 J * aj__ ~aj@x4db0ee03.dyn.telefonica.de
1477967397 Q * derjohn_mobi Ping timeout: 480 seconds
1477978899 M * Bertl_oO  off to bed now ... have a good one everyone!
1477978902 N * Bertl_oO Bertl_zZ
1477979185 Q * FireEgl Ping timeout: 480 seconds
1477979774 J * FireEgl Fire_OFTC@2604:2d80:8410:c1b8:b05c:312b:90c0:e1fd
1477987172 J * eipi-1 ~eipi-1@00021f49.user.oftc.net
1477987254 M * eipi-1 any IT's or Net Admins here?
1477987802 Q * eipi-1 Quit: Leaving
1477993977 Q * Romster Ping timeout: 480 seconds
1477994041 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1477994677 Q * aj__ Ping timeout: 480 seconds
1477996228 J * aj__ ~aj@b2b-94-79-172-98.unitymedia.biz
1478000070 J * ensc|w ~ensc@gw-27.sigma-chemnitz.de
1478000485 Q * Romster Ping timeout: 480 seconds
1478001253 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1478002097 J * Ghislain ~ghislain@adsl1.aqueos.com
1478002737 Q * Romster Ping timeout: 480 seconds
1478003352 N * Bertl_zZ Bertl
1478003358 M * Bertl  morning folks!
1478004022 M * CcxWrk Hello Bertl! :-)
1478004130 M * CcxWrk Signed patches and proper tls certificate when? ;-)
1478004157 M * Bertl the moment you wire the money :)
1478004217 M * CcxWrk Letsencrypt is free, so is gnupg/signify. :P
1478004230 M * Bertl yeah, but my time is not
1478004303 M * CcxWrk Though yeah, I might be able to convince $employer. Nothing too grand though.
1478004756 M * Bertl as long as it covers my time, it's fine for me, I'm not against it
1478005175 M * CcxWrk How much do you think it would actually take to do that? And to fix the script that updates the wiki I guess.
1478005208 M * CcxWrk I've been using simp_le for the certs btw. Quite painless and no automagic.
1478005230 M * Bertl well, depends on what 'features' you expect
1478005249 M * Bertl I typically upload the patches to the server and run the update script
1478005289 M * Bertl adding some kind of checksum/signature in a separate file is probably the simplest way to go
1478005325 M * CcxWrk Yeah. Most projects use gpg detached signature. And signify also works when you want something more lightweight.
1478005334 M * Bertl signing the diff directly should be doable as well, but I don't know how diff works with that
1478005392 M * Bertl adding links to the signatures in the wiki requires changing the script (which I haven't written) so probably takes some time
1478005521 M * Bertl with Letsencrypt I haven't played around yet, but from a fellow admin I know that it requires regular re-activation, so it has the potential to be 'broken' on a regular basis :)
1478005568 M * CcxWrk I'd be content if I had a secure way to automatically pull new patches. Wiki is rather secondary to that (though then I'd write it there, so people don't keep thinking we're still at 3.x)
1478005666 M * CcxWrk letsencrypt issues limited-time certs, but you can keep the keypair forever, so you can stick it into TLSA or monkeysphere or whatever too
1478005735 M * Bertl so how exactly would a setup which makes you/your employer happy look like?
1478005944 N * Hungerhu Hunger
1478006654 M * CcxWrk Each patch file having a detached signature either by sha2 & >=2048bit RSA gpg key or Ed25519 signify one. Publish the pubkey at several verifiable places. That's about it.
1478007243 Q * Guy- Remote host closed the connection
1478007248 J * Guy- ~korn@elan.rulez.org
1478007304 M * CcxWrk Nice to have: proper TLS cert, gpg key signed by well-known entity (eg. debian developer), working links from wiki homepage
1478007420 M * Bertl well, let's see, I need to update gpg on my development system, create and distribute a key, test a semi automated signing (so that I do not forget :)
1478007436 M * Bertl that will probably take about 5 hours
1478007474 M * Bertl and then I have to sign each updated patch and upload the signatures, so that will take about half an hour per month or so
1478007524 M * Bertl where is your company located?
1478007533 M * CcxWrk .cz
1478007582 M * Bertl will your company require an invoice or is e.g. a simple paypal transfer fine?
1478007648 M * CcxWrk I'll have to ask, but I'm sure they'd be way happier having an invoice.
1478007676 M * Bertl yeah, most likely
1478007693 M * CcxWrk You are based in USA, right?
1478007706 M * Bertl nope, Austria/Europe
1478007719 M * Bertl so kind of nearby :)
1478007800 M * CcxWrk Oh. That makes it easier. You have fun internal timezone though judging by the IRC messages. :P
1478007836 M * Bertl yep, BUT (Bertl's Unique Timezone) :)
1478007916 M * Bertl okay, so let's say 80 EUR per hour for the 5h block, and 50 EUR per month on a quarterly basis (to reduce the number of invoices)
1478008014 M * CcxWrk I'm ~28h awake right now… so also fun.
1478008030 M * Bertl that is always fun :)
1478008140 M * CcxWrk Ok. I wonder why you expect making/uploading signatures to be so much effort though. Don't you have automated release script already?
1478008184 M * CcxWrk BTW how do you envision the future of the VServer project?
1478008207 M * Bertl I tried that some years ago but they always broke with kernel changes and broken cleanup scripts, etc
1478008276 M * Bertl as soon as LXC is fit enough to replace Linux-VServer, the kernel patches will disappear and only userspace tools/wrappers will remain 
1478008502 M * CcxWrk Do you actually see that happening? We've been stuck midway that effort for quite some time. What about the version gap to vanilla master? Even if stuff gets added it'll be a hurdle to jump to that version, won't it?
1478008566 M * Bertl LXC is slowly getting actively used, so I'm pretty confident, they will iron out the kinks and issues over time
1478008567 M * CcxWrk In the meantime the security issues keep piling up for the old kernels.
1478008621 M * CcxWrk What is still missing from making vserver work on vanilla? Could some features be sacrificed so it could?
1478008623 M * Bertl Linux-VServer gets ported to most long term versions and every now and then we have a port to the most recent vanilla version
1478008648 M * Bertl sec, phone, brb
1478008655 M * CcxWrk Sure :)
1478009210 M * Bertl well, the problem with LXC at the moment is that it lacks a number of isolation and most virtualization features
1478009274 M * Bertl some of the isolation features can be compensated with tricky security framework setups
1478009322 M * Bertl but on the virtualization side there is not much to do without kernel support
1478009502 M * CcxWrk Yeah, I've actually looked into LSM api the other day. Surprisingly I didn't find any hook into setuid() (I wanted p9auth/factotum to have uid0-less setup)
1478009742 M * CcxWrk What is missing on the virtualization side of things? I know the networking is different, but veth seems to work okay in most cases.
1478009859 M * Bertl mostly things like memory/swap/cpu shown inside a container and stuff like that
1478009918 M * CcxWrk I also see various statistic info being virtualized when looking at caps, plus per-guest time. Those all seem to not be a total necessity.
1478009973 M * Bertl well, you can get away without most of the virtualization features if you don't mind host information leaking into the guest
1478010007 M * Bertl (especially if the guest apps do not check/require proc)
1478010168 M * CcxWrk Hmm, does lxc expose host's process info in /proc? That could be considered security issue. Other than that I don't seem to find anything that'd be a problem.
1478010188 M * Bertl check /proc/meminfo for example
1478010220 M * Bertl or load average inside a container, etc
1478010321 M * Bertl the uptime is an example you can probably live with, but it's also confusing if somebody renting a guest restarts the guest and the uptime shows a few years or so
1478010341 M * Bertl might also be used to target systems based on exploit dates
1478010465 M * CcxWrk Yeah. Luckily I use VServer as a single-owner security solution. Actually dunno how people can live with having just one guest… how the heck do you organize your stuff into separate security domains without it? :]
1478010536 M * CcxWrk So I guess for me personally it's just up to the security boundaries that lxc lacks.
1478010550 M * Bertl that is actually an application where Linux-VServer has some advantages over LXC if used properly ... because you can get rid of the 'init' process
1478010581 M * CcxWrk Sadly the simpler security modules don't really understand namespaces. :/
1478010583 M * Bertl (if you do a per service isolation)
1478010625 M * Bertl I'm pretty confident the security modules will all get context/namespace aware sooner or later
1478010694 M * CcxWrk I prefer to have runit in there as pid1. I don't like unsupervised daemons and supervising them via persistent context and exec is kinda hacky.
1478010797 M * CcxWrk And it's tiny either way. Alpine(musl) vservers weigh tens of megabytes total.
1478011086 M * CcxWrk So if I wanted to write a LSM that would fill in the missing VServer security features, what would I have to implement? Some mounting stuff I presume, xattr stuff perhaps? Maybe quotas, though I've never used those. And a chroot-barrier analogy. Did I miss something.
1478011161 M * Bertl really depends on what Linux-VServer features you use
1478011210 M * Bertl if you don't mind having almost no virtualization (i.e. get the host system values in /proc, etc) and you are fine with init based isolation as well as veth (full network)
1478011232 M * Bertl then you just need to fix the holes in LXC with some LSM
1478011491 M * CcxWrk I have some other ideas about what to do with networking there which should be feasible. But yeah, that seems like it for most of my installs.
1478012073 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1478013175 Q * Romster Ping timeout: 480 seconds
1478013232 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1478019389 Q * aj__ Remote host closed the connection
1478021113 J * derjohn_mob ~aj@x4db0ee03.dyn.telefonica.de
1478022000 Q * derjohn_mob Remote host closed the connection
1478022493 J * derjohn_mob ~aj@x4db0ee03.dyn.telefonica.de
1478022638 Q * neofutur Ping timeout: 480 seconds
1478022977 Q * derjohn_mob Ping timeout: 480 seconds
1478022998 J * derjohn_mob ~aj@x4db0ee03.dyn.telefonica.de
1478026218 Q * Ghislain Quit: Leaving.
1478027354 Q * derjohn_mob Remote host closed the connection
1478027785 Q * Romster Ping timeout: 480 seconds
1478028099 J * derjohn_mob ~aj@x4db0ee03.dyn.telefonica.de
1478028122 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1478031213 Q * derjohn_mob Ping timeout: 480 seconds
1478033831 J * derjohn_mob ~aj@x4db0ee03.dyn.telefonica.de
1478035060 Q * derjohn_mob Ping timeout: 480 seconds
1478035430 J * derjohn_mob ~aj@x4db0ee03.dyn.telefonica.de
1478037181 M * Bertl  off for a nap ... bbl
1478037182 N * Bertl Bertl_zZ
1478043559 Q * Romster Ping timeout: 480 seconds
1478043696 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com