[gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
Andrew Savchenko posted on Sun, 29 Mar 2015 21:04:52 +0300 as excerpted: > On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote: >> On 29.03.2015 19:39, Andrew Savchenko wrote: >> > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: >> >> So I would like to propose that >> >> >> >> * support for Git access through https:// is activated, >> >> >> >> * Git access through http:// and git:// is deactivated, and >> > >> > Some people have https blocked. http:// and git:// must be available >> > read-only. >> >> They would not do online banking over http, right? Why would they run >> code with root privileges from http? > > Gentoo tree access is not even near on the same security scale as online > banking. The point is, if the gentoo tree is compromised and you install from it, everything you run including that online banking is now effectively compromised, so it most certainly *IS* at the same security scale as that online banking. Weakest link in the chain and all that... Unless of course you use something non-gentoo for that banking, or, I suppose, only do updates over "trusted" wireline connections (you trust your ISP, your gentoo mirror and its ISP, and all backbone connections in between), but do online banking over public wifi with unverified and untrusted hotspots... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] rfc: add-on files handling improvements
On Sun, Mar 29, 2015 at 07:49:32PM -0400, Rich Freeman wrote: > On Sun, Mar 29, 2015 at 7:28 PM, William Hubbs wrote: > > On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote: > >> > >> > Thoughts? > >> > >> One point in favor of the current practice (installing add-on files > >> unconditionally) is the fact that you can basically do it for free - you > >> neither have to depend on additional packages, nor is the presence of > >> the add-on files a penalty in download time or storage. > > > > The add-on files i'm talking about are not specifically used by the > > packages that install them. They are add-ons that hook the packages into > > external functions, such as shell completions, logrotate files, xinetd > > configurations, etc. > > > > The penalty is cruft on the users's systems when they don't use the > > programs that read these files, such as app-admin/logrotate, > > sys-apps/xinetd, etc. > > The problem is that if you don't install this stuff up-front you end > up rebuilding half your system to install it later. > > I think the cleanest solution is to just install this stuff > unconditionally, and users who really object to having it around can > use INSTALL_MASK. It is just a couple of inodes, on a distro that by > default sticks a dozen inodes for every package in the repository on > their root partition. *snip* > Not everybody uses logrotate, xinetd, cron.d, and so on. It still > makes sense to just install the files, since they passively sit there > doing nothing in those cases. Rich, Not everyone uses zsh either, but you just said in the other thread that it is acceptable to put zsh completions behind a use flag [1], and a couple of others agreed with us. So, if we are going to do that for zsh, I'm just wanting to attempt defining what is common vs what isn't, and no, I don't think we should bug the council with this every time it comes up about a package. William [1] https://archives.gentoo.org/gentoo-dev/message/d57b96bcfb1a91ee437f39410da00aad signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to "full multilib"
On Mon, Mar 30, 2015 at 1:12 AM, Rich Freeman wrote: > On Sun, Mar 29, 2015 at 5:56 PM, Davide Pesavento wrote: >> On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman wrote: >> >>> qt is a pretty significant package to have break with multilib, and >>> trying to run qt-5 on a stable system is already a nightmare with the >>> qtchooser switch (in my case I ended up abandoning qt5 as I didn't >>> need it that badly). >> >> I'm not sure how qt5 is relevant to this discussion. >> > > As I understand it, qt5 cannot be installed side-by-side with the > current stable qt4, but it can be installed side-by-side with 4.8.6. > My understanding is that this is the result of the same overall > ebuild/eclass changes. Therefore, it is another reason to stabilize > 4.8.6. You are correct that it has nothing to do with the multilib > changes otherwise. > Your understanding is correct, and I agree it is indeed another reason to stabilize 4.8.6. Thanks for clarifying. Regards, Davide
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-03-29 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2015-03-29 23:59 UTC. Removals: dev-python/py-freebsd 2015-03-24 01:24:48 idella4 dev-python/cherryflow 2015-03-24 02:46:31 idella4 dev-python/colubrid 2015-03-24 02:46:58 idella4 dev-python/genetic 2015-03-24 02:47:20 idella4 dev-python/gnosis-utils 2015-03-24 02:47:59 idella4 dev-python/ldaptor 2015-03-24 02:49:38 idella4 dev-python/g-pypi 2015-03-24 02:54:53 idella4 dev-util/spe2015-03-24 02:57:01 idella4 app-text/pyrpub 2015-03-24 02:59:43 idella4 app-emulation/fig 2015-03-25 00:39:47 alunduil Additions: virtual/python-cffi 2015-03-23 09:53:15 idella4 x11-terms/pangoterm 2015-03-24 07:51:19 tranquility sys-fs/duperemove 2015-03-25 00:15:43 rich0 dev-python/pychroot 2015-03-25 04:20:16 radhermit net-misc/nxplayer 2015-03-26 14:29:15 voyageur dev-python/pyshark 2015-03-26 17:55:35 vapier dev-perl/Devel-Cover2015-03-27 16:30:57 chainsaw x11-misc/light-locker 2015-03-27 16:40:06 calchan sci-biology/embassy-meme2015-03-28 17:17:41 jlec sci-biology/embassy-clustalomega2015-03-28 17:33:53 jlec app-arch/vimball2015-03-29 01:41:37 radhermit media-fonts/open-sans 2015-03-29 07:17:53 yngwin media-fonts/gidole 2015-03-29 07:33:06 yngwin media-fonts/exo 2015-03-29 08:00:08 yngwin media-fonts/viga2015-03-29 08:18:31 yngwin app-vim/pyclewn 2015-03-29 09:33:28 maksbotan kde-base/libkgreeter2015-03-29 11:33:07 johu sci-biology/dialign22015-03-29 14:22:43 jlec -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-python/py-freebsd,removed,idella4,2015-03-24 01:24:48 dev-python/cherryflow,removed,idella4,2015-03-24 02:46:31 dev-python/colubrid,removed,idella4,2015-03-24 02:46:58 dev-python/genetic,removed,idella4,2015-03-24 02:47:20 dev-python/gnosis-utils,removed,idella4,2015-03-24 02:47:59 dev-python/ldaptor,removed,idella4,2015-03-24 02:49:38 dev-python/g-pypi,removed,idella4,2015-03-24 02:54:53 dev-util/spe,removed,idella4,2015-03-24 02:57:01 app-text/pyrpub,removed,idella4,2015-03-24 02:59:43 app-emulation/fig,removed,alunduil,2015-03-25 00:39:47 Added Packages: virtual/python-cffi,added,idella4,2015-03-23 09:53:15 x11-terms/pangoterm,added,tranquility,2015-03-24 07:51:19 sys-fs/duperemove,added,rich0,2015-03-25 00:15:43 dev-python/pychroot,added,radhermit,2015-03-25 04:20:16 net-misc/nxplayer,added,voyageur,2015-03-26 14:29:15 dev-python/pyshark,added,vapier,2015-03-26 17:55:35 dev-perl/Devel-Cover,added,chainsaw,2015-03-27 16:30:57 x11-misc/light-locker,added,calchan,2015-03-27 16:40:06 sci-biology/embassy-meme,added,jlec,2015-03-28 17:17:41 sci-biology/embassy-clustalomega,added,jlec,2015-03-28 17:33:53 app-arch/vimball,added,radhermit,2015-03-29 01:41:37 media-fonts/open-sans,added,yngwin,2015-03-29 07:17:53 media-fonts/gidole,added,yngwin,2015-03-29 07:33:06 media-fonts/exo,added,yngwin,2015-03-29 08:00:08 media-fonts/viga,added,yngwin,2015-03-29 08:18:31 app-vim/pyclewn,added,maksbotan,2015-03-29 09:33:28 kde-base/libkgreeter,added,johu,2015-03-29 11:33:07 sci-biology/dialign2,added,jlec,2015-03-29 14:22:43 Done.
Re: [gentoo-dev] Review: Apache AddHandler news item
Next round: * Recipe for handling "\.(php|php5|phtml|phps)\." manually added * AddType (with similar problems) mentioned, too * Typo "momment" fixed (* Internel revision bump to 3, will be committed as revision 1) (* Date bumped to today) (* Links renumbered due to new link [2]) Title: Apache AddHandler/AddType vulnerability protection Author: Sebastian Pipping Content-Type: text/plain Posted: 2015-03-30 Revision: 3 News-Item-Format: 1.0 Display-If-Installed: www-servers/apache Apache's directives AddHandler [1] (and AddType [2]) can be used to map certain file name extensions (e.g. .php) to a handler (e.g. application/x-httpd-php). While a line like AddHandler application/x-httpd-php .php .php5 .phtml matches index.php, it also matches index.php.png. Apache's notes on multiple file extensions [3] document a multi-language website as a context where that behavior may be helpful. Unfortunately, it can be a security threat. Combined with (not just PHP) applications that support file upload, the AddHandler/AddType directive can get you into remote code execution situations. That is why app-admin/eselect-php now avoids AddHandler and is shipping SetHandler application/x-httpd-php instead. Why this news entry? * Since Apache configuration lives below /etc, you need to run etc-update (or a substitute) to actually have related fixes applied. * If you are currently relying on AddHandler to execute secret_database_stuff.php.inc, moving away from AddHandler could result in serving your database credentials in plain text. A command like find /var/www/ -name '*.php.*' \ -o -name '*.php5.*' \ -o -name '*.phtml.*' may help discovering PHP files that would no longer be executed. Shipping automatic protection for this scenario is not trivial, but you could manually install protection based on this recipe: # a) Apache 2.2 / Apache 2.4 + mod_access_compat #Order Deny,Allow #Deny from all # b) Apache 2.4 + mod_authz_core #Require all denied # c) Apache 2.x + mod_rewrite #RewriteEngine on #RewriteRule .* - [R=404,L] * You may be using AddHandler (or AddType) at other places, including off-package files. Please have a look. * app-admin/eselect-php is not the only package affected. There is a dedicated tracker bug at [4]. As of the moment, affected packages include: app-admin/eselect-php[apache2] dev-lang/php[apache2] net-nds/gosa-core www-apache/mod_fastcgi www-apache/mod_flvx www-apache/mod_python www-apache/mod_suphp www-apps/moinmoin www-apps/rt[-lighttpd] Thanks to Nico Suhl, Michael Orlitzky and Marc Schiffbauer. [1] https://httpd.apache.org/docs/current/mod/mod_mime.html#addhandler [2] https://httpd.apache.org/docs/current/mod/mod_mime.html#addtype [3] https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext [4] https://bugs.gentoo.org/show_bug.cgi?id=544560
Re: [gentoo-dev] rfc: add-on files handling improvements
On Sun, Mar 29, 2015 at 7:28 PM, William Hubbs wrote: > On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote: >> >> > Thoughts? >> >> One point in favor of the current practice (installing add-on files >> unconditionally) is the fact that you can basically do it for free - you >> neither have to depend on additional packages, nor is the presence of >> the add-on files a penalty in download time or storage. > > The add-on files i'm talking about are not specifically used by the > packages that install them. They are add-ons that hook the packages into > external functions, such as shell completions, logrotate files, xinetd > configurations, etc. > > The penalty is cruft on the users's systems when they don't use the > programs that read these files, such as app-admin/logrotate, > sys-apps/xinetd, etc. The problem is that if you don't install this stuff up-front you end up rebuilding half your system to install it later. I think the cleanest solution is to just install this stuff unconditionally, and users who really object to having it around can use INSTALL_MASK. It is just a couple of inodes, on a distro that by default sticks a dozen inodes for every package in the repository on their root partition. You suggested that the past policy was due to the lack of --changed-use in portage at the time, but this is not the case. That option has been around for a very long time. Maybe if it first came up for manpages or docs that might have been the case, but certainly not in more recent cases. Not everybody uses logrotate, xinetd, cron.d, and so on. It still makes sense to just install the files, since they passively sit there doing nothing in those cases. -- Rich
Re: [gentoo-dev] rfc: add-on files handling improvements
On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote: > > > Thoughts? > > One point in favor of the current practice (installing add-on files > unconditionally) is the fact that you can basically do it for free - you > neither have to depend on additional packages, nor is the presence of > the add-on files a penalty in download time or storage. The add-on files i'm talking about are not specifically used by the packages that install them. They are add-ons that hook the packages into external functions, such as shell completions, logrotate files, xinetd configurations, etc. The penalty is cruft on the users's systems when they don't use the programs that read these files, such as app-admin/logrotate, sys-apps/xinetd, etc. All I'm saying is if the application that processes these small files is not installed, I don't think the files should be either, unless the upstream build system forces it; I guess we shouldn't try to do anything about that. > Further, a lot of packages install _small_ additional files > unconditionally - let it be examples, minimal documentation, example > configurations - unconditionally. And this is done with the very same > reasoning as above; the penalty is small enough to not warrant the > introduction of a use flag. The small files I'm talking about, technically, aren't used by the package that installs them; they are used by another package, which may or may not be installed, independently from the package that installs the small files. > Personally, I would not introduce yet another set of global use flags > just for the sake of controlling everything with use flags. The > complexity this introduces (naming choice - enforcing the rule - > ensuring uniformity) is worse than the current behavior of just > installing small add-on files. Actually I'm not talking about introducing more use flags; the flags I'm interested in adding this functionality to are already there. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to "full multilib"
On Sun, Mar 29, 2015 at 5:56 PM, Davide Pesavento wrote: > On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman wrote: > >> qt is a pretty significant package to have break with multilib, and >> trying to run qt-5 on a stable system is already a nightmare with the >> qtchooser switch (in my case I ended up abandoning qt5 as I didn't >> need it that badly). > > I'm not sure how qt5 is relevant to this discussion. > As I understand it, qt5 cannot be installed side-by-side with the current stable qt4, but it can be installed side-by-side with 4.8.6. My understanding is that this is the result of the same overall ebuild/eclass changes. Therefore, it is another reason to stabilize 4.8.6. You are correct that it has nothing to do with the multilib changes otherwise. -- Rich
Re: [gentoo-dev] rfc: add-on files handling improvements
> Thoughts? One point in favor of the current practice (installing add-on files unconditionally) is the fact that you can basically do it for free - you neither have to depend on additional packages, nor is the presence of the add-on files a penalty in download time or storage. Further, a lot of packages install _small_ additional files unconditionally - let it be examples, minimal documentation, example configurations - unconditionally. And this is done with the very same reasoning as above; the penalty is small enough to not warrant the introduction of a use flag. Personally, I would not introduce yet another set of global use flags just for the sake of controlling everything with use flags. The complexity this introduces (naming choice - enforcing the rule - ensuring uniformity) is worse than the current behavior of just installing small add-on files. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*
On Sun, 29 Mar 2015 17:49:50 +0200 Michał Górny wrote: > > Michał, as already discussed with Pacho [1], emul-linux-x86-jna can > > just go away entirely. Nothing requires it and it doesn't make any > > sense without emul-linux-x86-java though I note that isn't in the > > list either; I thought it would be. Java herd is struggling with > > the regular VM packages enough as it is, we could really do without > > supporting this one as well. I very much doubt that end users need > > it any more. Any objections to removing it? > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=474464#c5 > > I don't really want to touch Java stuff, so I'd prefer if you handled > that yourself. That said, feel free to add it to the same p.mask > entry. Just make sure not to break the dependency graph :). Okay. It'll also mean killing off sun-j2me-bin and proguard, which we seem to be cool with (very dead), and getting novell-groupwise-client to always use the bundled JRE. I need dilfridge's input on the latter. -- James Le Cuirot (chewi) Gentoo Linux Developer pgprcZKTnT0wB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to "full multilib"
On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman wrote: > I think we really need to either stabilize 4.8.6, or backport > qtchooser/multilib/etc to the current stable version. > Backporting is not an option. The introduction of multilib support in qt4 required extensive changes to the eclass (substantial portions of code were rewritten) and the ebuilds. Therefore stabilizing 4.8.6-r1 is the way to go. We had surprisingly few regressions, but the ones that are still unsolved are proving quite hard to debug. Please help with the blockers of bug #530238. As usual, at least for me, the problem is the lack of time for gentoo development, plus the fact that very few people are actively working on qt{4,5} packaging (kensington, me, and more recently yngwin). > qt is a pretty significant package to have break with multilib, and > trying to run qt-5 on a stable system is already a nightmare with the > qtchooser switch (in my case I ended up abandoning qt5 as I didn't > need it that badly). > I'm not sure how qt5 is relevant to this discussion. Thanks, Davide
[gentoo-dev] rfc: add-on files handling improvements
All, I want to start a discussion about our add-on files practice and try to improve it. I agree it is reasonable to install bash completions unconditionally, because bash is part of the base requirement for Gentoo. However, I do not agree that we should continue installing add-on files for everything under the sun unconditionally. I believe, back in the day we started this practice, portage did not support --newuse or --changed-use, so there was no way to only update packages that had changed or new use flags. In that situation, I understand why we installed all of these add-on files unconditionally and told users to use INSTALL_MASK if they wanted them not to be on their systems. However, I feel that we should update our practice now since we have these features available to us and to our users. In my previous thread about zsh, it was suggested that I could use the zsh-completion use flag to control zsh-completion installation, and not rdepend on zsh. This is now how pybugz is set up. The suggestion was made because zsh is not common, so let's try to define what common means to get an idea of when use flags can be used like this. I think the most fair/objective way to define whether something is common is whether or not it is part of the base requirement, like bash, or whether it is the default provided by a virtual. In either of those cases, I would say it makes sense to install add-on files that the program might use unconditionally. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On Sun, Mar 29, 2015 at 9:12 PM, Matthias Schwarzott wrote: > On 29.03.2015 20:58, Matthias Schwarzott wrote: >> Hi there! >> >> I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). >> Since then valgrind did no longer work for 32bit programs because >> "-march=native" did choose instructions that valgrind does not support >> in 32bit mode (even ld.so was unusable). >> >> After some research I put this into make.conf and now it works: >> CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" >> CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" >> >> Is this the best solution to the problem? >> If yes, the valgrind ebuild could suggest something like this. >> Either always show it or check cpu-flags first (is this maintainable?). >> > I should add, that it seems to break for exactly one package: mariadb > Not only mariadb, there are other known breakages... see https://bugs.gentoo.org/show_bug.cgi?id=541616#c5 According to mgorny (Cc'ed): "You are not supposed to touch CFLAGS_x86, ever. That's some magic stuff that's used in profiles & multilib.eclass." Regards, Davide
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On 03/29/15 15:07, Matt Turner wrote: On Sun, Mar 29, 2015 at 11:58 AM, Matthias Schwarzott wrote: Hi there! I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). Since then valgrind did no longer work for 32bit programs because "-march=native" did choose instructions that valgrind does not support in 32bit mode (even ld.so was unusable). After some research I put this into make.conf and now it works: CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" Is this the best solution to the problem? If yes, the valgrind ebuild could suggest something like this. Either always show it or check cpu-flags first (is this maintainable?). Valgrind's policy is that they don't implement new instruction sets in 32-bit. Doing what you've done is the only option I'm aware of, short of implementing support in valgrind for these instructions. This is a known issue. I could add a pkg_postinst() message, but with valgrind, there would be lots of caveats. Maybe open a bug and we'll track the issue in gentoo that way, like the strlen issue and a few other valgrind oldies. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 23:35:54 +0600 "Vadim A. Misbakh-Soloviov" wrote: > Despite of all you're talking about is right from paranoid point of > view, I'd, anyway, say "DO NOT DO THAT", because you propose to > revoke the right of choice from the users. A "right of choice" from the user only makes sense if there is a reasonable choice. Just to take this to the extreme: Should we add a heartbleed-enabled version of openssl back to the portage tree? It's the choice of the user if they want to have heartbleed enabled, right? If there is no disadvantage for the more secure protocols then there is no need for a choice. > Moreover, there are some times where it is impossible to fetch > sources via "secure" way, but you need it right here and right now. This has been said before, also in the thread about the webpage. Can you say what times that would be? Basically these days it's not possible to use the mainstream internet without https (you can't search google or log into facebook without https). I'd really like to hear of any real world situation where this is an issue. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpQ0bCBb3afe.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On 29.03.2015 20:58, Matthias Schwarzott wrote: > Hi there! > > I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). > Since then valgrind did no longer work for 32bit programs because > "-march=native" did choose instructions that valgrind does not support > in 32bit mode (even ld.so was unusable). > > After some research I put this into make.conf and now it works: > CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" > CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" > > Is this the best solution to the problem? > If yes, the valgrind ebuild could suggest something like this. > Either always show it or check cpu-flags first (is this maintainable?). > I should add, that it seems to break for exactly one package: mariadb # file /usr/lib32/libmysqlclient.so.18.0.0 /usr/lib32/libmysqlclient.so.18.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped After commenting the flags again: # file /usr/lib32/libmysqlclient.so.18.0.0 /usr/lib32/libmysqlclient.so.18.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped Regards Matthias
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On Sun, Mar 29, 2015 at 11:58 AM, Matthias Schwarzott wrote: > Hi there! > > I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). > Since then valgrind did no longer work for 32bit programs because > "-march=native" did choose instructions that valgrind does not support > in 32bit mode (even ld.so was unusable). > > After some research I put this into make.conf and now it works: > CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" > CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" > > Is this the best solution to the problem? > If yes, the valgrind ebuild could suggest something like this. > Either always show it or check cpu-flags first (is this maintainable?). Valgrind's policy is that they don't implement new instruction sets in 32-bit. Doing what you've done is the only option I'm aware of, short of implementing support in valgrind for these instructions.
[gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
Hi there! I updated my ~amd64 system recently to new hardware (Intel Core i3-4160). Since then valgrind did no longer work for 32bit programs because "-march=native" did choose instructions that valgrind does not support in 32bit mode (even ld.so was unusable). After some research I put this into make.conf and now it works: CFLAGS_x86="${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" CXXFLAGS_x86="${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2" Is this the best solution to the problem? If yes, the valgrind ebuild could suggest something like this. Either always show it or check cpu-flags first (is this maintainable?). Regards Matthias
Re: [gentoo-dev] Re: multilib amd64 news item for review
Dnia 2015-03-29, o godz. 21:31:49 Nikos Chantziaras napisał(a): > On 29/03/15 21:00, Andrew Savchenko wrote: > > */* long list of 433 flags > > Yeah, just noticed that I can't split the lines. > > I then tried to define an array of USE flags in make.conf: > >GLOBAL_USE_FLAGS=( ... ) > > so that I can then use that array in package.use, but for some reason > make.conf doesn't accept arrays :-/ Because make.conf is only pseudo-shell that is parsed with a broken pseudo-shell parser. -- Best regards, Michał Górny pgpkgTJzc4mqd.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: multilib amd64 news item for review
On 29/03/15 21:00, Andrew Savchenko wrote: */* long list of 433 flags Yeah, just noticed that I can't split the lines. I then tried to define an array of USE flags in make.conf: GLOBAL_USE_FLAGS=( ... ) so that I can then use that array in package.use, but for some reason make.conf doesn't accept arrays :-/
[gentoo-dev] Re: [gentoo-user] Re: This nite's switch to "full multilib"
(crossposting to -dev since this is fairly high-impact) On Sun, Mar 29, 2015 at 1:27 PM, Michael Palimaka wrote: > On 30/03/15 03:43, waben...@gmail.com wrote: >> >> I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed >> but I had no problems with that. >> >> I'm on gentoo stable (not ~amd64) and I don't use KDE. > > If you're on stable, you'll need to keyword qt-4.8.6 in its entirety. > You can't mix and match versions, and 4.8.6 is the only one that > supports multilib. I think we really need to either stabilize 4.8.6, or backport qtchooser/multilib/etc to the current stable version. qt is a pretty significant package to have break with multilib, and trying to run qt-5 on a stable system is already a nightmare with the qtchooser switch (in my case I ended up abandoning qt5 as I didn't need it that badly). -- Rich
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, Mar 29, 2015 at 1:52 PM, Sebastian Pipping wrote: > On 29.03.2015 19:39, Andrew Savchenko wrote: >> On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: >>> So I would like to propose that >>> >>> * support for Git access through https:// is activated, >>> >>> * Git access through http:// and git:// is deactivated, and >> >> Some people have https blocked. http:// and git:// must be >> available read-only. > > They would not do online banking over http, right? Why would they run > code with root privileges from http? > I don't see the point in disabling it. Certainly we should support ssl though. If people want to obtain their code over http they should be permitted to do so. Even without using ssl it is easy to just check that your commit hash is correct and it becomes as tamper-proof as sha1 (tell me again why the scm of the future is still using sha1?). -- Rich
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
> GitHub does not support git:// but only secure protocols (HTTPS, SSH), GitHub DO (!) support git:// $ git clone git://github.com/msva/mva-overlay.git Cloning into 'mva-overlay'... remote: Counting objects: 10435, done. remote: Compressing objects: 100% (41/41), done. remote: Total 10435 (delta 11), reused 0 (delta 0), pack-reused 10393 Receiving objects: 100% (10435/10435), 2.99 MiB | 758.00 KiB/s, done. Resolving deltas: 100% (5132/5132), done. Checking connectivity... done. > see [2]. "shoud-i-use" != "do not support" -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
> OpenPGP (GPG is just one implementation), but indeed, > that is what the gentoo-keys project is about. There is experimental > support for OpenPGP verification in portage already using gkeys. > Currently the focus is on getting developer's keys up to GLEP63 specs, > i currently see 36 good Gentoo developer keys. The scheme is also > flexible enough to allow for overlays. > > > https is not a good protection against MITM when factoring in global > PKIX CA setup, nor would it protect with regards to server compromise. > So the only viable way to secure ebuild repositories is proper OpenPGP > usage. I'd double that pedant paranoid! :) -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
> Doesn't git:// uses SSH wich is secure? I think that was on github. git+ssh:// — does. git:// — does not. It is just git-daemon listening on separate port and serving plaintext, readonly (by default) access. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/29/2015 06:41 PM, Sebastian Pipping wrote: > Hi! > ... > > * Why do we serve Git over git:// and http:// if those are > vulnerable to man-in-the-middle attacks (before having waterproof > GPG protection for whole repositories in place)? OpenPGP (GPG is just one implementation), but indeed, that is what the gentoo-keys project is about. There is experimental support for OpenPGP verification in portage already using gkeys. Currently the focus is on getting developer's keys up to GLEP63 specs, i currently see 36 good Gentoo developer keys. The scheme is also flexible enough to allow for overlays. > Especially with ebuilds run by root, we cannot afford MITM. > > > So I would like to propose that > > * support for Git access through https:// is activated, https is not a good protection against MITM when factoring in global PKIX CA setup, nor would it protect with regards to server compromise. So the only viable way to secure ebuild repositories is proper OpenPGP usage. - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJVGD9LAAoJEP7VAChXwav6VmsIALlhZ1g1GXYAL/ZkP+vi1L0H MLKfYcxkMgZNwEfykmRP4DvafNPDDhWT0gvFfD+vG4zucI7liQSUnzK8SbVtzz3l o/cCELtOvjq6pMnefizwxoG0IyJmu07Tu2kUPo3Qyw1I5IqHqaqFWDB/Noe5Rvuy rbXgWqMgg6rcYxOhUHN4YQFtw1xEgWW4CS8Smri2jjSRaizgQ2sw+Iji/ej4XUyW JvWdZfGfHuzTX/uWPr7ptyi9foVvTkc9Hko2t97XS/bNZvtECRNceZBOTGgHftgD nCopTHBY42G69B+z07qctdI2AH2ozskI1+42rE2k6vJLNfFcY5loidsWDPiG3a8= =9GQH -END PGP SIGNATURE-
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
> > They would not do online banking over http, right? Why would they run > code with root privileges from http? 1) Actually, they will :( 2) Because they can't review what bank received via insecure channel, while they can review what they're themselves received via http/git. -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote: > On 29.03.2015 19:39, Andrew Savchenko wrote: > > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: > >> So I would like to propose that > >> > >> * support for Git access through https:// is activated, > >> > >> * Git access through http:// and git:// is deactivated, and > > > > Some people have https blocked. http:// and git:// must be > > available read-only. > > They would not do online banking over http, right? Why would they run > code with root privileges from http? Gentoo tree access is not even near on the same security scale as online banking. Best regards, Andrew Savchenko pgpNDyzmTqg3y.pgp Description: PGP signature
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On 29.03.2015 19:56, Diamond wrote: > Doesn't git:// uses SSH wich is secure? I think that was on github. git:// is "the git protocol" [1] "with absolutely no authentication" and no encryption. GitHub does not support git:// but only secure protocols (HTTPS, SSH), see [2]. Best, Sebastian [1] http://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol [2] https://help.github.com/articles/which-remote-url-should-i-use/
Re: [gentoo-dev] Re: multilib amd64 news item for review
On Sun, 29 Mar 2015 19:43:51 +0200 Michał Górny wrote: > Dnia 2015-03-29, o godz. 20:35:27 > Andrew Savchenko napisał(a): > > > On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote: > > > > If this is not the case, and "*/* abi_x86_32" in package.use really > > > > does > > > > something different, then this is implemented in a way too confusing > > > > for > > > > people and should be considered a bug :-/ > > > > > > Yes, USE support in make.conf is a big pile of random misbehaviors > > > and bugs that need to be killed with fire. > > > > The proposal above is an absolute madness, especially for global > > USE flags. > > > > Why users should deal with dozens (if not hundreds useless */*)? > > To get sane, consistent and predictable config for a start. But you > know that you can specify multiple flags on one line, right? I'm well aware of that.. > In fact, '*/* ' is shorter than 'USE=""'! Only for short sets. For a long list of USE flags right now I have: USE=" flag1 -flag2 flag3 ... flag433 " This is an easily maintainable list, which is alphabetically sorted (it is trivial to do in vim). Why 433 flags? Because for flags common to more than a single package I don't want to duplicate them. For unique flags I have 225 entries (with comments) in package.use. With your proposal I have three alternatives: 1. */* long list of 433 flags Hard to read, hard to maintain, no benefits. 2. */* flag1 */* -flag2 */* flag3 ... */* flag433 A lot of useless stuff, no benefits. 3. */* \ flag1 \ -flag2 \ flag3 \ ... \ flag433 A lot of useless stuff, no benefits, easy to make mistake (e.g. forgot "\" after a new flag and have a lot of stuff broken). Best regards, Andrew Savchenko pgppjXewzvxKD.pgp Description: PGP signature
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: > Hi! > > > For the current Gentoo Git setup I found these methods working for > accessing a repository, betagarden in this case: > > git://anongit.gentoo.org/proj/betagarden.git > (git://git.gentoo.org/proj/betagarden.git) > (git://git.overlays.gentoo.org/proj/betagarden.git) > > http://anongit.gentoo.org/git/proj/betagarden.git > > (http://cgit.gentooexperimental.org/proj/betagarden.git) > > git+ssh://g...@git.gentoo.org/proj/betagarden.git > (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git) > > Those without braces are the ones announced at the repository's page > [1]. > > My concerns about the current set of supported ways of transfer are: > > * There does not seem to be support for https://. Please add it. > > * Why do we serve Git over git:// and http:// if those are vulnerable >to man-in-the-middle attacks (before having waterproof GPG >protection for whole repositories in place)? >Especially with ebuilds run by root, we cannot afford MITM. > > > So I would like to propose that > > * support for Git access through https:// is activated, > > * Git access through http:// and git:// is deactivated, and > > * the URLs on gitweb.gentoo.org and the Layman registry are >updated accordingly. (Happy to help with the latter.) > > > Thanks for your consideration. > > Best, > > > > Sebastian > > > [1] https://gitweb.gentoo.org/proj/betagarden.git/ > > Doesn't git:// uses SSH wich is secure? I think that was on github.
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On 29.03.2015 19:39, Andrew Savchenko wrote: > On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: >> So I would like to propose that >> >> * support for Git access through https:// is activated, >> >> * Git access through http:// and git:// is deactivated, and > > Some people have https blocked. http:// and git:// must be > available read-only. They would not do online banking over http, right? Why would they run code with root privileges from http? Best, Sebastian
[gentoo-dev] Re: multilib amd64 news item for review
On 29/03/15 20:28, Michał Górny wrote: Dnia 2015-03-29, o godz. 19:59:19 Nikos Chantziaras napisał(a): According to emerge --info, ABI_X86 seems to append, not override. In make.conf: ABI_X86="32" Then: $ emerge --info | grep -i abi_x86 You get: ABI_X86="32 64" "64" seems to be always there. You cannot override it. Using ABI_X86="32" in make.conf seems to only append "32" to the default. Portage may do that because it's forced by default. But some packages 'unforce' it, and that's when it matters. If this is not the case, and "*/* abi_x86_32" in package.use really does something different, then this is implemented in a way too confusing for people and should be considered a bug :-/ Yes, USE support in make.conf is a big pile of random misbehaviors and bugs that need to be killed with fire. Looks like I'm moving USE flags and abi_x86_32 into package.use... I hope that doesn't compromise emerge --info output for bugzilla issues?
Re: [gentoo-dev] Re: multilib amd64 news item for review
Dnia 2015-03-29, o godz. 20:35:27 Andrew Savchenko napisał(a): > On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote: > > > If this is not the case, and "*/* abi_x86_32" in package.use really does > > > something different, then this is implemented in a way too confusing for > > > people and should be considered a bug :-/ > > > > Yes, USE support in make.conf is a big pile of random misbehaviors > > and bugs that need to be killed with fire. > > The proposal above is an absolute madness, especially for global > USE flags. > > Why users should deal with dozens (if not hundreds useless */*)? To get sane, consistent and predictable config for a start. But you know that you can specify multiple flags on one line, right? In fact, '*/* ' is shorter than 'USE=""'! -- Best regards, Michał Górny pgpdNQzPcaXHj.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: multilib amd64 news item for review
On Sun, 29 Mar 2015 20:35:27 +0300 Andrew Savchenko wrote: > The proposal above is an absolute madness, especially for global > USE flags. > > Why users should deal with dozens (if not hundreds useless */*)? The syntax for package.use allows multiple flags per line, and comments... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote: > So I would like to propose that > > * support for Git access through https:// is activated, > > * Git access through http:// and git:// is deactivated, and Some people have https blocked. http:// and git:// must be available read-only. Best regards, Andrew Savchenko pgpMY89uyP7TG.pgp Description: PGP signature
Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
Despite of all you're talking about is right from paranoid point of view, I'd, anyway, say "DO NOT DO THAT", because you propose to revoke the right of choice from the users. It is user's decision, which protocol to use to fetch the sources. Although, you're, of course, free to make layman to fetch "official" repos from https, but not http/git protocols by default. Moreover, there are some times where it is impossible to fetch sources via "secure" way, but you need it right here and right now. В письме от Вс, 29 марта 2015 18:41:33 пользователь Sebastian Pipping написал: > Hi! > > > For the current Gentoo Git setup I found these methods working for > accessing a repository, betagarden in this case: > > git://anongit.gentoo.org/proj/betagarden.git > (git://git.gentoo.org/proj/betagarden.git) > (git://git.overlays.gentoo.org/proj/betagarden.git) > > http://anongit.gentoo.org/git/proj/betagarden.git > > (http://cgit.gentooexperimental.org/proj/betagarden.git) > > git+ssh://g...@git.gentoo.org/proj/betagarden.git > (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git) > > Those without braces are the ones announced at the repository's page [1]. > > My concerns about the current set of supported ways of transfer are: > > * There does not seem to be support for https://. Please add it. > > * Why do we serve Git over git:// and http:// if those are vulnerable >to man-in-the-middle attacks (before having waterproof GPG >protection for whole repositories in place)? >Especially with ebuilds run by root, we cannot afford MITM. > > > So I would like to propose that > > * support for Git access through https:// is activated, > > * Git access through http:// and git:// is deactivated, and > > * the URLs on gitweb.gentoo.org and the Layman registry are >updated accordingly. (Happy to help with the latter.) > > > Thanks for your consideration. > > Best, > > > > Sebastian > > > [1] https://gitweb.gentoo.org/proj/betagarden.git/ -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: multilib amd64 news item for review
On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote: > > If this is not the case, and "*/* abi_x86_32" in package.use really does > > something different, then this is implemented in a way too confusing for > > people and should be considered a bug :-/ > > Yes, USE support in make.conf is a big pile of random misbehaviors > and bugs that need to be killed with fire. The proposal above is an absolute madness, especially for global USE flags. Why users should deal with dozens (if not hundreds useless */*)? Best regards, Andrew Savchenko pgp3bqx8yyxIN.pgp Description: PGP signature
Re: [gentoo-dev] Should Gentoo do https by default?
On Sun, 29 Mar 2015 19:23:51 +0200 Michał Górny wrote: > Xperia X10 Mini, with ancient Android 2.1. > > bugs.gentoo.org works, though it complains about hostname mismatch (I > guess it doesn't handle wildcard certs or sth). Not exactly, it can't handle servers with more than one SSL certificate per IP. A wildcard certificate probably would work. Android 2.3 (Gingerbread) is the last release and probably the only OS of any significant concern to not support SNI at all. Even XP does with certain browsers. I know that particular phone and to be fair, it's pretty poor. That 240x320 screen surely hurts your eyes. ;) You could probably pick up something better for nothing. That phone can also be rooted quite easily (I've done it) and then flashed with something more recent. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpnCRFXGIzBb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: multilib amd64 news item for review
Dnia 2015-03-29, o godz. 19:59:19 Nikos Chantziaras napisał(a): > On 29/03/15 19:24, Michał Górny wrote: > > Dnia 2015-03-29, o godz. 19:14:43 > > Nikos Chantziaras napisał(a): > > > >> On 17/03/15 18:29, Michał Górny wrote: > >>> Dnia 2015-03-17, o godz. 16:55:32 > >>> René Neumann napisał(a): > >>> > Am 17.03.2015 um 16:33 schrieb Michał Górny: > >However, some > > users may prefer setting ABI_X86 globally to enable 32-bit libraries > > in all packages that support building them. This can be done using > > the following package.use entry: > > > >*/* abi_x86_32 > > > > I'm confused: Has this a different semantics from adding > USE+='abi_x86_32' to make.conf? If no, why mention this strange way > (which is new to me) for setting default global useflags. > >>> > >>> Because this is how users learn new fun stuff. Like sane configuration. > >> > >> I don't see why ABI_X86 is not the sane option. Using wildcards in > >> package.use is what sounds insane to me. > > > > Because it overrides the defaults without providing a way to append to > > them. > > According to emerge --info, ABI_X86 seems to append, not override. In > make.conf: > >ABI_X86="32" > > Then: > >$ emerge --info | grep -i abi_x86 > > You get: > >ABI_X86="32 64" > > > "64" seems to be always there. You cannot override it. Using > ABI_X86="32" in make.conf seems to only append "32" to the default. Portage may do that because it's forced by default. But some packages 'unforce' it, and that's when it matters. > > If this is not the case, and "*/* abi_x86_32" in package.use really does > something different, then this is implemented in a way too confusing for > people and should be considered a bug :-/ Yes, USE support in make.conf is a big pile of random misbehaviors and bugs that need to be killed with fire. -- Best regards, Michał Górny pgpTYXut6UTdz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Should Gentoo do https by default?
Dnia 2015-03-29, o godz. 18:50:17 Hanno Böck napisał(a): > On Sun, 29 Mar 2015 16:46:05 +0200 > Michał Górny wrote: > > > While I don't mind this entirely, we need to make sure to get things > > right. For example, I'm quite unhappy being unable to use Forums or > > sources.g.o from my phone because of some SSL issues… > > Can you be more specific on that? Of course if there are problems we > should fix them - and I'm glad to help in analyzing those. > (However there are some unfortunate issues that are hard to fix, e.g. > some devices relying on broken protocols like sslv3 - but I think these > should be rare) > > What phone? Should we move such issues to bugzilla? (cc me if you open > a bug) Xperia X10 Mini, with ancient Android 2.1. bugs.gentoo.org works, though it complains about hostname mismatch (I guess it doesn't handle wildcard certs or sth). forums.gentoo.org, sources.gentoo.org it first complains about untrusted issuer, and after telling it to configure tries a bit more and gives 'Unable to connect to server, try again later.' -- Best regards, Michał Górny pgpJMrdIriBa1.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC News item: FFmpeg default
Ben de Groot wrote: > Title: FFmpeg default > Posted: 2015-04-01 Bad date for such news. //Peter
[gentoo-dev] Re: multilib amd64 news item for review
On 29/03/15 19:24, Michał Górny wrote: Dnia 2015-03-29, o godz. 19:14:43 Nikos Chantziaras napisał(a): On 17/03/15 18:29, Michał Górny wrote: Dnia 2015-03-17, o godz. 16:55:32 René Neumann napisał(a): Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. Because this is how users learn new fun stuff. Like sane configuration. I don't see why ABI_X86 is not the sane option. Using wildcards in package.use is what sounds insane to me. Because it overrides the defaults without providing a way to append to them. According to emerge --info, ABI_X86 seems to append, not override. In make.conf: ABI_X86="32" Then: $ emerge --info | grep -i abi_x86 You get: ABI_X86="32 64" "64" seems to be always there. You cannot override it. Using ABI_X86="32" in make.conf seems to only append "32" to the default. If this is not the case, and "*/* abi_x86_32" in package.use really does something different, then this is implemented in a way too confusing for people and should be considered a bug :-/
Re: [gentoo-dev] Should Gentoo do https by default?
On Sun, 29 Mar 2015 16:46:05 +0200 Michał Górny wrote: > While I don't mind this entirely, we need to make sure to get things > right. For example, I'm quite unhappy being unable to use Forums or > sources.g.o from my phone because of some SSL issues… Can you be more specific on that? Of course if there are problems we should fix them - and I'm glad to help in analyzing those. (However there are some unfortunate issues that are hard to fix, e.g. some devices relying on broken protocols like sslv3 - but I think these should be rare) What phone? Should we move such issues to bugzilla? (cc me if you open a bug) -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpyyxhG77Xma.pgp Description: OpenPGP digital signature
[gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks
Hi! For the current Gentoo Git setup I found these methods working for accessing a repository, betagarden in this case: git://anongit.gentoo.org/proj/betagarden.git (git://git.gentoo.org/proj/betagarden.git) (git://git.overlays.gentoo.org/proj/betagarden.git) http://anongit.gentoo.org/git/proj/betagarden.git (http://cgit.gentooexperimental.org/proj/betagarden.git) git+ssh://g...@git.gentoo.org/proj/betagarden.git (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git) Those without braces are the ones announced at the repository's page [1]. My concerns about the current set of supported ways of transfer are: * There does not seem to be support for https://. Please add it. * Why do we serve Git over git:// and http:// if those are vulnerable to man-in-the-middle attacks (before having waterproof GPG protection for whole repositories in place)? Especially with ebuilds run by root, we cannot afford MITM. So I would like to propose that * support for Git access through https:// is activated, * Git access through http:// and git:// is deactivated, and * the URLs on gitweb.gentoo.org and the Layman registry are updated accordingly. (Happy to help with the latter.) Thanks for your consideration. Best, Sebastian [1] https://gitweb.gentoo.org/proj/betagarden.git/
Re: [gentoo-dev] Re: multilib amd64 news item for review
Dnia 2015-03-29, o godz. 19:14:43 Nikos Chantziaras napisał(a): > On 17/03/15 18:29, Michał Górny wrote: > > Dnia 2015-03-17, o godz. 16:55:32 > > René Neumann napisał(a): > > > >> Am 17.03.2015 um 16:33 schrieb Michał Górny: > >>> However, some > >>> users may prefer setting ABI_X86 globally to enable 32-bit libraries > >>> in all packages that support building them. This can be done using > >>> the following package.use entry: > >>> > >>> */* abi_x86_32 > >>> > >> > >> I'm confused: Has this a different semantics from adding > >> USE+='abi_x86_32' to make.conf? If no, why mention this strange way > >> (which is new to me) for setting default global useflags. > > > > Because this is how users learn new fun stuff. Like sane configuration. > > I don't see why ABI_X86 is not the sane option. Using wildcards in > package.use is what sounds insane to me. Because it overrides the defaults without providing a way to append to them. > Are you suggesting that the sane way of setting USE flags globally is > moving them from make.conf into package.use and use wildcards to set > them globally? Yes. > >> And to bring this even further: Wouldn't the nicest approach to add > >> ABI_X86="32" > > > > This will disable some 64-bit web browser plugins. > > I don't see why the package.use wildcard wouldn't do that too. It is applied on top of the default rather than overriding it. > >> ABI_X86="32 64" > >> to make.conf? (With the latter being more descriptive, as the first one > >> might suggest that _only_ 32bit should be built). > > > > This will enable some possibly-unwanted 64-bit software, e.g. 64-bit > > Windows support in wine. > > I don't see why the package.use wildcard wouldn't do that too. Ditto. -- Best regards, Michał Górny pgpMbkABIYH83.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC News item: FFmpeg default
Dnia 2015-03-30, o godz. 00:07:16 Ben de Groot napisał(a): > Title: FFmpeg default > Author: Ben de Groot > Content-Type: text/plain > Posted: 2015-04-01 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: virtual/ffmpeg > > Since the choice between ffmpeg and libav has been made more > explicit, there has been a lot of discussion about what the > default implementation should be. It can be concluded that > media-video/ffmpeg has wider support, and would be somewhat > more convenient for most end-users. > > For this reason the default implementation has been switched > back from media-video/libav to media-video/ffmpeg by removing > the libav useflag from the base profile. > > If the libav useflag is already globally enabled or disabled > in /etc/portage/make.conf, then no further action is required. > > Users who implicitly relied on libav being enabled in their > profile, and who wish to continue using libav, should enable > this in their local /etc/portage configuration. Include example code. Also please prepare an update to the USE=libav news item to state updated default. -- Best regards, Michał Górny pgpitKpfm_2ac.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: multilib amd64 news item for review
On 17/03/15 18:29, Michał Górny wrote: Dnia 2015-03-17, o godz. 16:55:32 René Neumann napisał(a): Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. Because this is how users learn new fun stuff. Like sane configuration. I don't see why ABI_X86 is not the sane option. Using wildcards in package.use is what sounds insane to me. Are you suggesting that the sane way of setting USE flags globally is moving them from make.conf into package.use and use wildcards to set them globally? And to bring this even further: Wouldn't the nicest approach to add ABI_X86="32" This will disable some 64-bit web browser plugins. I don't see why the package.use wildcard wouldn't do that too. ABI_X86="32 64" to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). This will enable some possibly-unwanted 64-bit software, e.g. 64-bit Windows support in wine. I don't see why the package.use wildcard wouldn't do that too.
[gentoo-dev] RFC News item: FFmpeg default
Title: FFmpeg default Author: Ben de Groot Content-Type: text/plain Posted: 2015-04-01 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: virtual/ffmpeg Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable this in their local /etc/portage configuration. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*
Dnia 2015-03-29, o godz. 11:57:12 James Le Cuirot napisał(a): > On Sun, 29 Mar 2015 12:13:32 +0200 > Pacho Ramos wrote: > > > > > > > Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to > > simply end up rdepending on > > >=virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no package in the > > >tree rdepends on this emul set and, then, > > packages outside portage could simply rdepend on libffi directly > > instead of needing to keep this > > Michał, as already discussed with Pacho [1], emul-linux-x86-jna can just > go away entirely. Nothing requires it and it doesn't make any sense > without emul-linux-x86-java though I note that isn't in the list either; > I thought it would be. Java herd is struggling with the regular VM > packages enough as it is, we could really do without supporting this > one as well. I very much doubt that end users need it any more. Any > objections to removing it? > > [1] https://bugs.gentoo.org/show_bug.cgi?id=474464#c5 I don't really want to touch Java stuff, so I'd prefer if you handled that yourself. That said, feel free to add it to the same p.mask entry. Just make sure not to break the dependency graph :). -- Best regards, Michał Górny pgpcg6iJ6xE0A.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Should Gentoo do https by default?
Dnia 2015-03-27, o godz. 15:33:15 Hanno Böck napisał(a): > I think defaulting the net to HTTPS is a big step for more security and > I think Gentoo should join the trend here. While I don't mind this entirely, we need to make sure to get things right. For example, I'm quite unhappy being unable to use Forums or sources.g.o from my phone because of some SSL issues… Do you really believe serving content insecurely is worse than serving no content at all? -- Best regards, Michał Górny pgpzn579fMX37.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
Dnia 2015-03-29, o godz. 14:22:56 "Andreas K. Huettel" napisał(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Donnerstag, 26. März 2015, 17:51:04 schrieb William Hubbs: > > > I'm seeing at least two ways of handling zsh completion files in the > > tree. > > > [...] > > > The other method is shown by dev-vcs/hub at least, and maybe several > > other packages -- e.g. unconditionally installing the completions > > according to our small files installation practice and not reflecting > > the rdepend on app-shells/zsh. > > > > I think we should be consistent with how we handle this, and personally > > I would vote for the first way since zsh is not all that common. > > However, if the feeling is that we should nuke the zsh-completion use > > flag, I'll be the first to do it, and I'll start opening bugs against > > other packages. > > Please let's nuke the useflag and install the files unconditionally. This is > the overall agreed policy for small add-on files. > > (The only real alternative would be to finally, please, please, please > introduce IUSE_RUNTIME. Which just got booted from EAPI=6 again.) IUSE_RUNTIME wouldn't allow you to change installed files. -- Best regards, Michał Górny pgpH1WLAQHN7H.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Donnerstag, 26. März 2015, 17:51:04 schrieb William Hubbs: > I'm seeing at least two ways of handling zsh completion files in the > tree. > [...] > The other method is shown by dev-vcs/hub at least, and maybe several > other packages -- e.g. unconditionally installing the completions > according to our small files installation practice and not reflecting > the rdepend on app-shells/zsh. > > I think we should be consistent with how we handle this, and personally > I would vote for the first way since zsh is not all that common. > However, if the feeling is that we should nuke the zsh-completion use > flag, I'll be the first to do it, and I'll start opening bugs against > other packages. Please let's nuke the useflag and install the files unconditionally. This is the overall agreed policy for small add-on files. (The only real alternative would be to finally, please, please, please introduce IUSE_RUNTIME. Which just got booted from EAPI=6 again.) - -- Andreas K. Huettel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVF+6gAAoJEB9VdM6hupKV0LAP/0NZxMJ0Gt+Fz89la1LTkfpq 88HehQQ7u69liFX+/EI+dWMS8ZCzg9H1VefhIWwDIC42LAVE+gPbheVBSgfcqFr2 8KLsPrl4Vp++XyidScE5CD71Oy/XXK6wsy8VoPQtppGAKEh56+cqIdSwUpU4W4yj o1blqw+/pnwuuxnwdVGuhrht24xVhMdZOTDGVpUqscxIiEvn9lDFQydy7OYZlk3n wQsQQ5SiCWZXHJjhSxbvRBSIzXVt4enp/f/mUpf+p3f16M2tS/ALeCpR/TB1o62d FPWCDPaMzxMaAIoxObQ021cRWOcZ09kBxJstI/7J1Vnw0W0zFyLlevJ6wmwoimGl Vav1zGZMk0cl/ft8c6nlRi876eDwpwGAhsF51MM4ijtB4mBkBveR+gLUjHDdOYWq jOqOysDF1Fv0JeVwJEpk71HotcN/ev1GE3DlveaGssT9lPb1sQrCRydkIxwKKuoQ v/AjeBkTSliQ0vtYID4hUdSlVTpkcdURqtckuXJiVxqxhOMh87XKuzR67R16hUU2 mgizmqYnlnSm9+cG4XKDE3y3q4w1QIynjZyjQJDWySaF7yV6SRSuyEaTK///1ufH k1E0NX9IG+9uIzxUgxhh3GqCy8h5pqFvXXHtGYJU5ipUVJCfVHQAGcWNY+qga6dB 3j1XVICXWyptqyXhfJFu =YceU -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*
On Sun, 29 Mar 2015 12:13:32 +0200 Pacho Ramos wrote: > > > Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to > simply end up rdepending on > >=virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no package in the > >tree rdepends on this emul set and, then, > packages outside portage could simply rdepend on libffi directly > instead of needing to keep this Michał, as already discussed with Pacho [1], emul-linux-x86-jna can just go away entirely. Nothing requires it and it doesn't make any sense without emul-linux-x86-java though I note that isn't in the list either; I thought it would be. Java herd is struggling with the regular VM packages enough as it is, we could really do without supporting this one as well. I very much doubt that end users need it any more. Any objections to removing it? [1] https://bugs.gentoo.org/show_bug.cgi?id=474464#c5 -- James Le Cuirot (chewi) Gentoo Linux Developer pgpoHyxHdr55C.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*
El sáb, 28-03-2015 a las 23:03 +0100, Michał Górny escribió: > # Michał Górny (14 Sep 2014) > # on behalf of gx86-multilib project > # Mask emul-linux-x86 packages along with unported old versions > # of reverse dependencies for removal in 60 days, bug #544876. > # Please use multilib ebuilds with abi_x86_32 instead. Thanks a lot! :D [...] > =virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no package in the tree rdepends on this emul set and, then, packages outside portage could simply rdepend on libffi directly instead of needing to keep this
Re: [gentoo-dev] Cluster tinderbox poc
El sáb, 28-03-2015 a las 17:20 +0100, Magnus Granberg escribió: > Hi > > As some of you may know, I have been working on code for a tinderbox with > frontend support. I think its time to move it to a offcial project. > The Proof-Of-Concept (poc) is almost ready, but it still have alot of the > frontend left to do. You can see the logs and summit bugsreports and > chose what to build. The poc is runing on a 64core box with help of ganeti > to manges the virtual machines (vm). I have 4 vm's runing for now but I will > add 4 more later. I'm building the vm's with help of > ganeti-instance-gentoobootstrap. The vm's query the db for what to build. > Db is update with tree info and list to builds for the vm's. The vm's are > runing python code that call portage api to build the packages in the list. > The frontend is just django. > > Featuers > -Support multiplay repos > -Support any arch there the python code can run. > -Attach the build logs. > -Use the db to store the repex for log search. > > /Magnus G. > > Thanks a lot :)