[gentoo-dev] Re: Re: Banning modification of pkg-config files
On Sat, May 10, 2014, Rich Freeman wrote: On Sat, May 10, 2014, hasufell wrote: Longterm, this makes it year after year more difficult to develop software for Linux. Instead (like valve), people start to develop for certain distros only (like Ubuntu), because it's just too much work to bother with all this hackery-here-hackery-there-incompatible-here things. Maybe also a reason they start to bundle all libraries for every single game (among the convenience factor), effectively decreasing security overall. I'm with you here, but what is the solution? He outlined the solution and seemant resolved the implementation difficulty question the day before your mail, amongst others, so I'm unsure why it wasn't simply accepted. It seems like a no-brainer to me, although it is a specific situation because lua is a language. The latter is more relevant to consideration of whether they are being unreasonable. The solution is trivial and it means you're fixing the correct upstream. So, in your mind what would a sane policy look like? Should packages like lua not provide pkg-config files even though apparently every other distro does? If so, where do we draw the line? Do we follow some particular distro like Debian? Do we list 4 distros and allow the file if 3/4 use it? If we don't allow a pkg-config in general can maintainers still have a gentoo-foo file? If we don't provide it, period, there's no line to draw. I'm not saying that applies to every package, but it self-evidently applies here, and I agree with hasufell that it applies everywhere, if we want to do more than follow the crowd for the sake of it, at the expense of our reputation of helping upstreams fix their builds. The upstream with the problem is more than happy to get a fix for the library they depend on, and the patch is trivial. Remember, no-one at all is talking about not shipping .pc; they're only talking about fixing a midstream consumer of an upstream which does NOT ship a .pc file. Is anyone seriously suggesting the midstream do not want to work with their upstream in all situations? If we want a firm policy then there needs to be a proposal for one that makes sense. Otherwise the council is 95% likely to just say we recommend that maintainers use care when creating pkg-config files but we leave it to their discretion, because that is the only thing that makes any sense when you can't come up with a rule that makes sense. The trouble with making general rules for specific situations is you always have to account for the exception to every rule, and more: keep reviewing the basis for the inevitable exceptions to see if they still have standing. But it appears you already have a policy that seems quite sane: On Mon, May 12, 2014, hasufell wrote: I said repeatedly... if it is the ONLY way to fix something, then we have good reason to bend the rule. (and even then it should be made hard, as in: open this for discussion first. In addition, all of these non-upstream files have to be documented as such.) However, currently, this is not a rule, just some policy people would rather ignore since it might cause you a bit more work. There does appear to be a trend to try to sideline the dev ML, on the basis that not all developers have to subscribe which is rich coming from one of its most prolific posters. Perhaps it's a phase, as istr similar periods in the past. There are good reasons why drobbins made the dev ML open to externals, who don't have a high rate of churn, and why the GLEP process requires wider discussion on this same list. I can think of several major changes that by all rights should have gone through GLEPs, as well as being worked on in overlay. What happened to the idea of getting professional results from an informal group of volunteers dedicated to that end? Maybe i dreamt those years, but some of your herds still manage it. Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: The gx86-multilib project needs your help! (+ roadmap reminder)
El mar, 13-05-2014 a las 15:23 -0400, Ian Stakenvicius escribió: On 13/05/14 03:19 PM, Pacho Ramos wrote: El dom, 11-05-2014 a las 20:56 +0200, Michał Górny escribió: [...] 4. whenever possible, depend on the specific subslot that is known to provide SONAME equal to the required by your package, e.g. for libgcrypt.so.20 you depend on libgcrypt:0/20, [...] Why is this needed? Thanks for the explanation :) I believe that this relates to cases of, by example, a 32bit pre-rolled binary package on amd64. I expect one could use a specific version range (upper/lower) for the dependency instead, so long as it is just as accurate. Ah, ok :)
Re: [gentoo-dev] Packages looking for new maintainers.
08.05.2014 08:07, Alex Alexander пишет: x11-misc/whaw Took this one, really neat and simple tool! -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Banning modification of pkg-config files
It's called keeping status quo.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Hi, Ryan Hill wrote: Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. Do you really think it is a good behavior to automatically disable something you can call a security feature? At least there should be a warning, not? Think about situations where the user just know network-sandbox is important, because it will protect my system from unwanted modifications (the thing where the test suite for example will write to the local, productive, database server...) and therefore explicitly enable that feature by hand. But the user is *also* using distcc to speed up the compilation/update time in his/her network. The user maybe knows that distcc is using network, but he/she might be surprised that it won't work together with the network-sandbox feature. If we now silently disable network-sandbox because the user also set distcc he/she might be even more surprised when he/she noticed that his/her local productive database system was accessed by emerge though he/she enabled network-sandbox feature to prevent this (but which was automatically disabled without a warning). Because it is security relevant and the impact could be a real problem I won't even show just a warning the user could miss. If network-sandbox *and* distcc are both set, emerge should fail complaining about the problem. This is something the user should be aware of and must be solved by hand. So if we decide to enable the network-sandbox feature by default (which we should do), users also using distcc must take action. And if in future we will solve the problem so that both features can be used together, we should send out a news item for people using the distcc feature telling them Now you can re-enable (the default) network-sandbox feature... -Thomas
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 4:12 AM, Thomas D. whi...@whissi.de wrote: Hi, Ryan Hill wrote: Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. Do you really think it is a good behavior to automatically disable something you can call a security feature? At least there should be a warning, not? I think you are reading much further into Ryan's statement than he intended. Think about situations where the user just know network-sandbox is important, because it will protect my system from unwanted modifications (the thing where the test suite for example will write to the local, productive, database server...) and therefore explicitly enable that feature by hand. But the user is *also* using distcc to speed up the compilation/update time in his/her network. The user maybe knows that distcc is using network, but he/she might be surprised that it won't work together with the network-sandbox feature. If we now silently disable network-sandbox because the user also set distcc he/she might be even more surprised when he/she noticed that his/her local productive database system was accessed by emerge though he/she enabled network-sandbox feature to prevent this (but which was automatically disabled without a warning). Because it is security relevant and the impact could be a real problem I won't even show just a warning the user could miss. If network-sandbox *and* distcc are both set, emerge should fail complaining about the problem. This is something the user should be aware of and must be solved by hand. So if we decide to enable the network-sandbox feature by default (which we should do), users also using distcc must take action. And if in future we will solve the problem so that both features can be used together, we should send out a news item for people using the distcc feature telling them Now you can re-enable (the default) network-sandbox feature... -Thomas
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 13:12:30 +0200 Thomas D. whi...@whissi.de wrote: Ryan Hill wrote: Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. Do you really think it is a good behavior to automatically disable something you can call a security feature? At least there should be a warning, not? Sandboxing isn't about security. It's about catching mistakes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 16:48:24 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Sandboxing isn't about security. It's about catching mistakes. Ciaran has a point here. Thomas, you assumed that network-sandbox is the only thing stopping an ebuild from accessing local services or the internet. However, even with network-sandbox being enabled such behaviour would still constitue a major bug which would be fixed by the devs. So yes, network-sandbox (and same goes for ipc-sandbox) is mainly a debugging aid for developers which will help them spot such problems more easily. -- Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Ciaran McCreesh: Sandboxing isn't about security. Sure it is.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Hi, Ciaran McCreesh wrote: Sandboxing isn't about security. It's about catching mistakes. From Wikipedia (http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29): In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites network-sandbox is using unshare() syscalls to separate... not? But when I wrote my mail I was referring to Michal's statements in http://thread.gmane.org/gmane.linux.gentoo.devel/91131. He is explicitly listing improving security... -Thomas
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 20:35:41 +0200 Thomas D. whi...@whissi.de wrote: Ciaran McCreesh wrote: Sandboxing isn't about security. It's about catching mistakes. From Wikipedia (http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29): In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites network-sandbox is using unshare() syscalls to separate... not? Not for security reasons: sandbox (the way it is used on Gentoo) does nothing against a malicious ebuild or a malicious package. Instead, it simply catches certain common mistakes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 14:44:58 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure. Secure against what? Malicious ebuilds? Malicious packages? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 14:44:58 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure. Secure against what? Malicious ebuilds? Malicious packages? Secure against unauthrorized network access during phases where network-sandbox is effective. I am aware that this is a very small benefit given that the ebuild or build system can do lots of things locally without network access, or install some file that accesses the network later. ipc-sandbox probably has some similar security benefit, but I don't understand it as well.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 12:01 PM, Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 14:44:58 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure. Secure against what? Malicious ebuilds? Malicious packages? Secure against unauthrorized network access during phases where network-sandbox is effective. I am aware that this is a very small benefit given that the ebuild or build system can do lots of things locally without network access, or install some file that accesses the network later. ipc-sandbox probably has some similar security benefit, but I don't understand it as well. I think we are way off topic here folks ;) -A
[gentoo-dev] Re: Adding -l (--ignore-whitespace) to EPATCH_COMMON_OPTS
On Thu, 15 May 2014 07:21:58 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 14 May 2014, Ryan Hill wrote: I'm a lazy bum and I'm tired of rebasing patches that fail due to whitespace. Is this doable or would it make the universe explode? Please don't. There are languages where whitespace is significant. Fair enough. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
