<    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 24 25  
26 27 28 29 30 31
00:34 jackmcbarn joined
00:45 laj joined
00:49 czart joined
01:00 orbiter joined
01:03 blueness joined
02:20 ogres joined
02:24 s33se joined
02:24 wonton_ joined
02:28 wonton joined
02:43 <kpcyrd> probably a lame question, but here you go: has anybody tried the alpine image on vultr? network doesn't seem to come up for me
02:59 wonton joined
03:00 coin3d joined
03:05 Emperor_Earth joined
03:13 wonton_ joined
03:16 Nobabs27 joined
03:16 fnljk_ joined
03:30 dirac1 joined
03:50 nwmcsween_ joined
03:50 <nwmcsween_> so trying out go and I get "go install runtime/internal/sys: open /usr/lib/go/pkg/linux_amd64/runtime/internal/sys.a: permission denied
03:50 <nwmcsween_> " on alpine
03:50 <nwmcsween_> thank you newline
03:54 jzono1 joined
04:01 dirac1 joined
04:31 <nwmcsween_> yeah go is effectively broken on alpine due to -buildmode=pie
04:31 <nwmcsween_> unless you use the sudo hammer
04:31 <Xe> nwmcsween_: how are you installing go?
04:31 <nwmcsween_> apk
04:32 <Xe> nwmcsween_: install libc6-compat and try the go tarball from upstream
05:20 iamthemcmaster joined
05:56 czart_ joined
06:00 fabled joined
06:35 coin3d joined
06:52 wazntmi joined
07:03 gogoprog joined
07:10 rnalrd joined
07:39 fekepp joined
08:26 t0mmy joined
08:34 tg joined
08:41 Ayyad joined
08:56 stwa joined
08:56 leo-unglaub joined
09:06 notkoos joined
09:06 <notkoos> hi; is libc.a still readily available somewhere?
09:18 jme joined
09:48 xsteadfastx joined
09:54 xsteadfastx joined
10:22 t0mmy joined
10:26 zhasha joined
10:27 <zhasha> Can anyone tell me where to find the hid-kensington driver in 3.5? :)
10:33 Caio joined
10:36 <ncopa> zhasha:
10:36 <ncopa> config-grsec.armhf:# CONFIG_HID_KENSINGTON is not set
10:36 <ncopa> config-grsec.x86:# CONFIG_HID_KENSINGTON is not set
10:36 <ncopa> config-grsec.x86_64:# CONFIG_HID_KENSINGTON is not set
10:37 <ncopa> zhasha: is it enough to enable it for edge only so far?
10:37 <zhasha> I'm completely new to apk but I'm not above installing a kernel from edge
10:37 <zhasha> just need to know how
10:37 <ncopa> i will upgrade the kernels today so i can enable this driver while at it
10:37 <zhasha> Awesome :)
10:38 <ncopa> in aport/main/linux-grsec, there are kernel configs
10:38 <ncopa> edit the config file, abuild checksum && abuild -r
10:38 <ncopa> and it should spit out a kernel package for you
10:38 <ncopa> but i think we should enable this in default kernel
10:38 <ncopa> zhasha: it would be nice if you could file an issue, for the history
10:39 <ncopa> http://bugs.alpinelinux.org/projects/alpine/issues
10:39 <ncopa> then i can include the issue number in commit message so in future, we know why it was added
10:51 <zhasha> I'll get on it
11:00 <ncopa> what kind of input dev is kensington?
11:03 <ncopa> does it make sense to enable this driver for armhf and aarch64?
11:04 <zhasha> it's a trackball
11:04 <zhasha> regular USB trackball
11:45 tmh1999 joined
12:06 blueness joined
12:20 blueness joined
12:31 cyborg-one joined
12:36 farosas_ joined
12:38 stwa joined
12:39 farosas_ joined
12:50 sparklyballs joined
13:30 mmlb joined
13:46 stwa joined
14:20 <zhasha> ncopa: sorry for the slowness http://bugs.alpinelinux.org/issues/7007
14:20 <zhasha> compiling the whole kernel on half the CPU power of a T61 was probably a bad idea
14:37 Skele joined
14:40 nabaz45 joined
14:44 afics joined
14:57 nanohest joined
14:59 xsteadfastx joined
15:02 xsteadfastx joined
15:42 norii joined
16:05 cyteen joined
16:07 Nobabs27 joined
16:16 mouthbreather joined
16:22 rollniak joined
16:23 <rollniak> hello everyone :D
16:30 nanohest joined
16:48 ogres joined
16:50 vidr joined
16:57 BitL0G1c joined
17:02 alacerda joined
17:22 notkoos left
17:30 fabled joined
17:40 wonton joined
17:47 BitL0G1c joined
18:23 Berra joined
18:31 cyborg-one joined
18:38 coin3d joined
18:40 blueness joined
18:47 wonton_ joined
18:53 wonton joined
18:53 Ayyad joined
18:53 sergey joined
18:55 wonton_ joined
19:00 wonton joined
19:02 wonton___ joined
19:09 ahrs joined
19:29 <ScrumpyJack> hi
19:43 gopar joined
19:58 gopar joined
20:23 mikeee_ joined
20:53 tmh1999 joined
21:00 nanohest joined
21:08 mikeee_ joined
21:17 saidso joined
21:18 blackwind_123 joined
21:23 <saidso> Hi there, I wonder if there is any historian around, I would like to understand how Alpine came to being and what is the relation with gentoo-hardened project? Anybody can point me right way?
21:24 blueness joined
21:25 <nwmcsween_> gentoo hardened was way before alpine
21:25 <nwmcsween_> like 2003 iirc
21:26 <nwmcsween_> and I think the pax team was originally on it or working with it (don't quote me on that)
21:34 <saidso> and Alpine was in the beginning something like gentoo overlay?
21:35 blueness joined
21:38 <jvoisin> pipacs is running some gentoo, yeah
21:38 gopar joined
21:40 <avih> saidso: http://git.net/ml/linux.leaf.devel/2005-08/msg00039.html link taken from the apline wikipedia page
21:48 <saidso> avih: awesome, good read. So it was gentoo hardened.. I am thinking of transmogrifying gentoo-hardened with the goal that would get me probably close to what Alpine is today. The idea is to retain more control over package compilation and use flags.. Just wonder how can I learn from history of Alpine
21:49 blueness joined
21:49 <darkfader> avih: how cool, i never saw that
21:50 <avih> googling "alpine linux history" tends to work ;)
21:50 <darkfader> oh so glad we moved away from udev :)
21:50 <darkfader> avih: :) never figured it went back that long
21:52 <nwmcsween_> the issue with gentoo is it's a pain
21:52 <Xe> ^
21:52 <nwmcsween_> if there was some sort of integration tests to make sure stuff didn't break all the time it might not be so bad
21:53 <Xe> nwmcsween_: linker errors are "fun" though!!!111!!
21:53 blueness joined
21:55 <saidso> nwmcsween_: yes, gentoo can be a pain, that is why I look into Alpine now
21:57 <saidso> I like the way how USE FLAGS work in gentoo, is there something similar in Alpine universe? (did some reading but not enough yet)
21:58 <nwmcsween_> no, if you want something like that and to be binary it would need a new distro
21:58 <nwmcsween_> prob using a bsdiff or something
21:59 <dalias> USE FLAGS are basically the reason why gentoo is a pain :)
22:00 <nwmcsween_> but it is handy sometimes when you don't want to pull in a huge dep chain
22:01 <dalias> yes, ideally there would be better solutions to that though
22:01 <dalias> like a stub lib that "provides foo"
22:02 Ayyad joined
22:04 <saidso> dalias: they can be double sided sword for sure, though I am not aware of any other way than LFS that would give you similar control/granularity of code running on your box
22:05 blueness joined
22:05 <nwmcsween_> it gets really complicated fast though, does stub lib provide 100% of the same api, same effects?
22:06 <nwmcsween_> I wanted to do it for automatically generating 'alternatives'
22:07 <nwmcsween_> e.g libev libevent compat api
22:07 blackwind_123 joined
22:09 <dalias> saidso, indeed; the granularity is what makes it a pain though
22:10 <dalias> and in some sense, i'd say you have more "control of the code running on your box" when you can prove (reproducible builds) that it matches what everyone else is getting rather than when it has the most trivial customizations
22:10 blueness joined
22:11 <dalias> because in the latter case it's actually hard to know if bugs or backdoors specific to your own build got baked in
22:11 <saidso> true, but you are outside of monoculture
22:11 cyteen joined
22:12 <TBB> it probably makes packaging a much bigger effort, but from a user's perspective the flags could be arranged hierarchically, for example, to make it a bit clearer
22:13 <TBB> reproducibility is a definitely a problem in a system of the level of granularity Gentoo has it
22:14 <TBB> can you really do more than just verify you're getting the same _source_ than the others...
22:15 <nwmcsween_> yes you could record compiler flags, version, etc, turn off timestamps, etc and hash the resulting output
22:17 <TBB> you could but if you think about the number of use flags in gentoo for example... okay, admittedly not every single flag applies to every single ebuild, but the amount of combinations would still be huge
22:17 <nwmcsween_> somewhat like bitcoin
22:17 <nwmcsween_> it would be vulnerable to a majority attack
22:18 <nwmcsween_> gentoo bins already does that though
22:18 <nwmcsween_> it records the use flags when creating binaries to ensure it can me installed
22:26 <saidso> thanks for ideas, I am still evaluating my requirements. What is the opinion on SELinux in Alpine community?
22:28 <nwmcsween_> can you actually use selinux and grsec?
22:29 blueness joined
22:29 <TBB> nothing stops you from using selinux, but using the two simultaneously is probably not worth the effort, and might even be impossible
22:29 <TBB> as a sidenote, I only speak for myself
22:30 <nwmcsween_> grsec has rbac or rsbac or something
22:30 <TBB> the advantage of selinux would be that you have plenty of resources for policies
22:30 <saidso> TBB: ok, I was using SELinux before, but not much experience with grsec config
22:31 <TBB> but the origin of selinux is what makes some people allergic, possibly for a reason
22:31 <saidso> TBB: yup, aware of that :D
22:32 <TBB> but grsecurity is nice, very nice. it will require a considerable amount of effort to use effectively, but it does a _lot_
22:33 blueness joined
22:33 <nwmcsween_> grsec and selinux are somewhat different, grsec rsbac and selinux are comparable
22:33 <nwmcsween_> err grsec rbac
22:33 <saidso> https://www.grsecurity.net/compare.php
22:34 <nwmcsween_> yes selinux is MAC only
22:34 <nwmcsween_> grsec has rbac but it isn't used in alpine
22:34 <saidso> it indeed does a lot.. sounds I will learn something new.
22:38 <nwmcsween_> kspp will eventually catch up to grsec in some form
22:38 <Xe> does alpine keep getting grsec patches?
22:39 <jvoisin> unstables ones
22:40 <jvoisin> TBB: "but grsecurity is nice, very nice. it will require a considerable amount of effort to use effectively, but it does a _lot_" I beg to disagree
22:40 <jvoisin> but maybe you're talking about RBAC
22:42 <nwmcsween_> so alpine doesn't have some deal with grsec over stable patches?
22:42 <nwmcsween_> it runs unstable?
22:42 <jvoisin> yes
22:43 <jvoisin> nwmcsween_: if alpine was getting stable patches, everyone could simply rip them off ;)
22:44 <nwmcsween_> they offered stable patches to previous users for free iirc
22:44 <jvoisin> *sponsors
22:58 <saidso> very interesting, was not aware of testing/sponsors grsec. Read up little bit about it https://lwn.net/Articles/313621/... so is it actually good idea to run Alpine with grsec testing patches on production infrastructure?
22:59 <saidso> or is Vanilla Alpine considered more stable?
23:00 <saidso> (Vanilla Kernel Alpine)
23:01 <nwmcsween_> do you trust unstable patch bombs?
23:01 <nwmcsween_> (basically what grsec does)
23:04 <darkfader> oh lol
23:05 <saidso> nope, but I got that SECURITY is a feature of Alpine based on https://www.alpinelinux.org/about/ and it says (while reading carefully) that having "unstable patch bombs" is an advantage.. while being rock-solid...
23:05 <darkfader> armchair sec discussion
23:06 <saidso> darkfader: hhhh just exploration
23:06 <darkfader> you can ask "has any of you ever experienced any negative outcome of having unstable grsec patches, ever"
23:06 <darkfader> try that
23:06 <jvoisin> nope, never
23:06 <nwmcsween_> then it's fine
23:07 <jvoisin> (for years)
23:10 <saidso> alright.. fair question.. empirical answer
23:10 <yGweSm1OzVHe> jvoisin: +1
23:18 darkfader joined
23:53 <avih> plus, if there's a grsec (or other kernel) issue, then it's likely to be detected while on edge, and handled before it turns into stable.
23:54 <avih> this probably applies to any issue in general, but just applies to grsec too.