Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
Yes, we should add possibilities, but not revoke them from user. That is a Gentoo Philosophy. We shouldn't enforce users to anything that, as we think, is better for them. Even about security. And yes, we even shouldn't forbid them to install heartbleaded openssl (thankfully, users is free to do that themselves from local overlays). -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Should Gentoo do https by default?
On 03/27/15 15:29, Hanno Böck wrote: > These days pretty much all big players use https only (google, > facebook, twitter, github, ...). You can't really use the > mainstream internet if your firewall blocks https. > Can we please stop making stuff up[1] just to make an argument seem stronger to the overly credulous? [1] http://www.google.com/search?q=this+is+not+impossible&gws_rd=ssl
回复：Re: [gentoo-dev] RFC News item: FFmpeg default
so. believe it or not? 在2015年03月30日 01:02，Peter Stuge 写道: Ben de Groot wrote: > Title: FFmpeg default > Posted: 2015-04-01 Bad date for such news. //Peter
Re: [gentoo-dev] ALLARCHES bugzilla keyword for stabilization requests
On 2015-03-30 17:14, James Le Cuirot wrote: > I tried to find the council meeting minutes where this was discussed > but to no avail. :( Sorry, I'm a bit slow. I'll be writing those up when I send out the next call for agenda items this week. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] ALLARCHES bugzilla keyword for stabilization requests
On Thu, 12 Mar 2015 13:35:16 +0100
"Andreas K. Huettel" wrote:
> as a result of the last council meeting we now have a new keyword
> ALLARCHES for stablerequest bugs on bugzilla.
We're thinking of applying this to Java because we have a massive
workload ahead of us and stabilization is making life even harder. I
intend to draw up a policy to outline when it should and shouldn't be
used; something along the lines of only pure Java (no native code) and
no calls to System.getProperty("os.arch"). Just want to confirm a
couple of things about it first.
Initial keywording still requires explicit testing on each arch, but
not necessarily by someone on the arch team, correct?
If an ebuild is stabilized for a bunch of archs through the use of
ALLARCHES but then some non-arch team member tests it on another arch
later (after the bug is closed), can they add the keyword as stable
immediately? If not then why not?
I tried to find the council meeting minutes where this was discussed
but to no avail. :(
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpFSNEImSUuj.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] arm64 profile deletes?
> On Mar 30, 2015, at 11:55 AM, Ulrich Mueller wrote: > >> On Mon, 30 Mar 2015, Alexandre Rostovtsev wrote: > On Mon, 2015-03-30 at 09:54 -0500, Tom Gall wrote: > Sorry for the trouble. My cvs history foo is a little weak but > it appears that someone went out and did some deleting in > profiles/arch/arm64 of some WIP things without bothering to > email, irc or otherwise communicate. > >> It seems that something went wrong with this commit: >> https://archives.gentoo.org/gentoo-commits/message/7fd131811947775b85faa93c720354df > >> The ChangeLog was updated, but the files were never uploaded to cvs. >> Maybe you either didn't cvs add the files or the cortex-* >> subdirectories before committing? > > Right, and I had reverted revision 1.7 of profiles/arch/arm64/ChangeLog > because it consisted of a ChangeLog entry only, but the cortex-* > subdirectories were missing. Also that commit broke the ChangeLog's > utf-8 encoding. Ah ha! See your email now. Thanks! > I sent an e-mail message informing Tom about my revert (with CC to qa) > at 2015-03-09. > > Ulrich
Re: [gentoo-dev] arm64 profile deletes?
> On Mon, 30 Mar 2015, Alexandre Rostovtsev wrote: >> > On Mon, 2015-03-30 at 09:54 -0500, Tom Gall wrote: >> >> Sorry for the trouble. My cvs history foo is a little weak but >> >> it appears that someone went out and did some deleting in >> >> profiles/arch/arm64 of some WIP things without bothering to >> >> email, irc or otherwise communicate. > It seems that something went wrong with this commit: > https://archives.gentoo.org/gentoo-commits/message/7fd131811947775b85faa93c720354df > The ChangeLog was updated, but the files were never uploaded to cvs. > Maybe you either didn't cvs add the files or the cortex-* > subdirectories before committing? Right, and I had reverted revision 1.7 of profiles/arch/arm64/ChangeLog because it consisted of a ChangeLog entry only, but the cortex-* subdirectories were missing. Also that commit broke the ChangeLog's utf-8 encoding. I sent an e-mail message informing Tom about my revert (with CC to qa) at 2015-03-09. Ulrich pgpXQJmWTRdIO.pgp Description: PGP signature
Re: [gentoo-dev] rfc: add-on files handling improvements
Hi, William Hubbs wrote: > 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. Are we talking about an actual problem? Are these "add-on files" causing real problems? How many "add-on files" on an average system are really useless (=cruft files) for most people and how much disk space do they take up? Do you remember the discussion about "USE flag per init system"? It was decided to drop the systemd USE flag if it is only controlling the installation of systemd service files and we didn't want to introduce a USE flag per init system because it doesn't scale. Also, image you are on OpenRC and decide to switch to systemd. If we wouldn't install the service files on every system the user would have to re-emerge his/her whole system to switch. Following your argumentation we would add an exception for init systems. So which add-on files are left? Logrotate! Doesn't the same argument against USE flags for each init system applies to things like logrotate, too? If not, at least the same argument "if you switch your init system" applies: If you decide to start using logrotate you would have to re-emerge your packages just for a 1kb file... Add another exception for logrotate files? :) I guess that's not what you want. But do you see the problem? How would you decide for which files you want to add an exception? Do you want to discuss with cron users if their cronjobs are add-on files or not? Some packages are providing files for logwatch. I don't expect that many desktop user will use logwatch. But do you want to start a discussion with non-desktop users if it is worth to re-emerge a whole package for 1kb additional files? Coming back to my first question: Why do you want to change the current situation? Are these "add-on files" causing any problems nowadays? Introducing another USE flag to control what INSTALL_MASK already do doesn't sound like a good way to go for me. But maybe I am not aware of a real problem you have with these "add-on files"... -Thomas
Re: [gentoo-dev] arm64 profile deletes?
On 30 Mar 2015 09:54, Tom Gall wrote: > Sorry for the trouble. My cvs history foo is a little weak but it appears > that someone went out and did some deleting in profiles/arch/arm64 of some > WIP > things without bothering to email, irc or otherwise communicate. just use the web viewer: https://sources.gentoo.org/profiles/arch/arm64/ that said, i don't see any recent commits in there from you ... maybe you made the changes to /usr/portage/profiles and didn't realize your cwd wasn't the cvs tree ? -mike signature.asc Description: Digital signature
Re: [gentoo-dev] arm64 profile deletes?
On Mon, 2015-03-30 at 10:37 -0500, Tom Gall wrote: > > On Mar 30, 2015, at 10:18 AM, Alexandre Rostovtsev > > wrote: > > > > On Mon, 2015-03-30 at 09:54 -0500, Tom Gall wrote: > >> Hi All, > >> > >> Sorry for the trouble. My cvs history foo is a little weak but it appears > >> that someone went out and did some deleting in profiles/arch/arm64 of some > >> WIP things without bothering to email, irc or otherwise communicate. > >> > >> A) Could the guilty party come forward? > >> > >> B) If there was something objectionable I’d like to understand what your > >> concern is. > >> > >> C) Helping out with arm64 is most welcome, please just don’t be pulling > >> nails from parts of the building under construction…. > >> > >> Thanks! > >> > >> Tom > >> tgall_foo aka CaptHammer > >> arm64 arch lead > > > > Don't know about profiles, but considering a long series of recent > > commits without a gpg signature [1] > > Obscure gpg-agent errors are so much fun. > > > and without ECHANGELOG_USER [2], you > > Already fixed. Joys of doing commits on a fresh gentoo arm64 install. > > > might have done something in /profiles that looked like "committing > > while drunk", and one of your fellow devs was compelled to revert ;) > > Very much doubt it. The list of arm64 devs I can count on one hand. > > > [1] > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/linux-headers/Manifest?r1=1.568&r2=1.569 > > [2] > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/linux-headers/ChangeLog?revision=1.431&view=markup > > It seems that something went wrong with this commit: https://archives.gentoo.org/gentoo-commits/message/7fd131811947775b85faa93c720354df The ChangeLog was updated, but the files were never uploaded to cvs. Maybe you either didn't cvs add the files or the cortex-* subdirectories before committing? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] arm64 profile deletes?
> On Mar 30, 2015, at 10:18 AM, Alexandre Rostovtsev > wrote: > > On Mon, 2015-03-30 at 09:54 -0500, Tom Gall wrote: >> Hi All, >> >> Sorry for the trouble. My cvs history foo is a little weak but it appears >> that someone went out and did some deleting in profiles/arch/arm64 of some >> WIP things without bothering to email, irc or otherwise communicate. >> >> A) Could the guilty party come forward? >> >> B) If there was something objectionable I’d like to understand what your >> concern is. >> >> C) Helping out with arm64 is most welcome, please just don’t be pulling >> nails from parts of the building under construction…. >> >> Thanks! >> >> Tom >> tgall_foo aka CaptHammer >> arm64 arch lead > > Don't know about profiles, but considering a long series of recent > commits without a gpg signature [1] Obscure gpg-agent errors are so much fun. > and without ECHANGELOG_USER [2], you Already fixed. Joys of doing commits on a fresh gentoo arm64 install. > might have done something in /profiles that looked like "committing > while drunk", and one of your fellow devs was compelled to revert ;) Very much doubt it. The list of arm64 devs I can count on one hand. > [1] > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/linux-headers/Manifest?r1=1.568&r2=1.569 > [2] > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/linux-headers/ChangeLog?revision=1.431&view=markup >
Re: [gentoo-dev] arm64 profile deletes?
On Mon, 2015-03-30 at 09:54 -0500, Tom Gall wrote: > Hi All, > > Sorry for the trouble. My cvs history foo is a little weak but it appears > that someone went out and did some deleting in profiles/arch/arm64 of some > WIP things without bothering to email, irc or otherwise communicate. > > A) Could the guilty party come forward? > > B) If there was something objectionable I’d like to understand what your > concern is. > > C) Helping out with arm64 is most welcome, please just don’t be pulling nails > from parts of the building under construction…. > > Thanks! > > Tom > tgall_foo aka CaptHammer > arm64 arch lead Don't know about profiles, but considering a long series of recent commits without a gpg signature [1] and without ECHANGELOG_USER [2], you might have done something in /profiles that looked like "committing while drunk", and one of your fellow devs was compelled to revert ;) [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/linux-headers/Manifest?r1=1.568&r2=1.569 [2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/linux-headers/ChangeLog?revision=1.431&view=markup signature.asc Description: This is a digitally signed message part
[gentoo-dev] arm64 profile deletes?
Hi All, Sorry for the trouble. My cvs history foo is a little weak but it appears that someone went out and did some deleting in profiles/arch/arm64 of some WIP things without bothering to email, irc or otherwise communicate. A) Could the guilty party come forward? B) If there was something objectionable I’d like to understand what your concern is. C) Helping out with arm64 is most welcome, please just don’t be pulling nails from parts of the building under construction…. Thanks! Tom tgall_foo aka CaptHammer arm64 arch lead
Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
On Mon, 30 Mar 2015 11:57:45 +0300 Andrew Savchenko wrote: > The Gentoo tree is not verified anyway: mirrors distribute it via > http, rsync and ftp. And using https for that will create a > tremendous stress on mirror's CPUs, so this is a bad approach. > Not to mention that https itself is very hapless protocol with tons > of vulnerabilities (all SSL versions are affected and most TLS > implementations). > > A proper solution will be to use cryptographic verification of > downloaded files. We should probably distinguish security of reading from Gentoo mirror and writing to it. But for paranoid ones we probably should add the option to read from https:// or other secured protocols too.
Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs
On 29.03.2015 23:29, Davide Pesavento wrote:
> 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."
>
I created this bug to track the issue:
https://bugs.gentoo.org/show_bug.cgi?id=545052
Regards
Matthias
Re: [gentoo-dev] rfc: add-on files handling improvements
On Sun, Mar 29, 2015 at 10:14 PM, William Hubbs wrote: > On Sun, Mar 29, 2015 at 07:49:32PM -0400, Rich Freeman wrote: > >> 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. That wasn't what I meant at all. I used the words "second choice" to describe this scenario. My first preference was to do what I quoted, which is to install the files unconditionally as is done with bash. If we did control it with a USE flag then we shouldn't RDEPEND on zsh. Apologies if my email was confusing. > [1] > https://archives.gentoo.org/gentoo-dev/message/d57b96bcfb1a91ee437f39410da00aad -- Rich
[gentoo-dev] Re: RFC: app-eselect category
Since I've seen only favourable replies, I'm going to create the category on Wednesday. I'll also take care of the package moves and of reverse dependencies. For the category metadata I currently have: The app-eselect category contains modules for the eselect configuration and administration tool. Die Kategorie app-eselect enthält Module für das Konfigurations- und Verwaltungswerkzeug eselect. If anyone wants further translations included (or improve the above versions :) then send them to me by e-mail. Please _don't_ send them to the list; I'll post the collected translations for review later. Ulrich pgpclVE5MP8Nr.pgp Description: PGP signature
Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
On Mon, 30 Mar 2015 05:37:01 + (UTC) Duncan wrote: > 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... The Gentoo tree is not verified anyway: mirrors distribute it via http, rsync and ftp. And using https for that will create a tremendous stress on mirror's CPUs, so this is a bad approach. Not to mention that https itself is very hapless protocol with tons of vulnerabilities (all SSL versions are affected and most TLS implementations). A proper solution will be to use cryptographic verification of downloaded files. Right now we have signed manifests and manifests can be used to verify all other data (ebuilds, distfiles, patches and so on). This is much more reliable solution, since it allows to verify data integrity even for compromised data channels or any infrastructure part not related to keys distribution or signing. What we really need is a tool to do such verification. This is work in progress now afaik. Best regards, Andrew Savchenko pgp2NewmxTXpU.pgp Description: PGP signature
