[gentoo-dev] IBM License

DAMAGES OR ANY DAMAGES WHATSOEVER ARISING * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN * IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES. Thanks, Jason [1] http://git.zx2c4.com/portage/tree/mail-mta/opensmtpd/opensmtpd-5.2.ebuild -- Jason

Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org

On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler a...@gentoo.org wrote: - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an initial wiki version of the document What is the current status of such a tool?

Re: [gentoo-dev] eselect init

If we're to support sysvinit and systemd at the same time, let each use their upstream paths. This means sysvinit gets /sbin/init. This also means that business can continue as usual, and nobody is forced to install eselect-init. The current system works for users who don't care or aren't aware

Re: [gentoo-dev] Sets in the tree

I've always found those class = something.that.is.clearly.portage.specific lines a bit of a bummer, since they're very tied to the internal functioning of portage and not a generic standard for how things should be defined. Before we add sets to the tree, maybe there should be some discussion

[gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

Hi Diego, So I recently published this: http://blog.zx2c4.com/749 , a local priv escalation. It doesn't work on Fedora because their /bin/su is compiled with -pie. (They don't compile gpasswd with -pie though, so they're still vulnerable.) In any case, what if we made it a policy in Gentoo to

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

On Mon, Jan 23, 2012 at 20:22, Diego Elio Pettenò flamee...@gentoo.orgwrote: Is it because of PIE alone or ASLR? Just curious it doesn't make much difference to me. When ASLR is turned on, the .text section of executables compiled with PIE is given a randomized base address. When ASLR is off

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

On Mon, Jan 23, 2012 at 20:37, Diego Elio Pettenò flamee...@gentoo.orgwrote: Stripping a compiled file of read permissions is quick, painless and (mostly) safe from errors. Changing the way it is compiled.. not so much. I'm not saying that it's not a good idea, but if we want to proceed with

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

To check for PIE, readelf -h /bin/su | grep Type If it says EXEC, no PIE. If it says DYN, yes PIE. -- sent from my mobile On 1/23/12, Mike Gilbert flop...@gentoo.org wrote: On Mon, Jan 23, 2012 at 2:40 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: That way, package maintainers could fix

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

On Mon, Jan 23, 2012 at 23:18, Zac Medico zmed...@gentoo.org wrote: We've got experimental support for FEATURES=xattr since portage-2.2.0_alpha80. We can include that in the next portage-2.1.x release. Awesome. If possible though, let's keep the no-SUID-ever discussion for another thread, as

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On Tue, Jan 24, 2012 at 06:58, Mike Frysinger vap...@gentoo.org wrote: pedantically, PIE+ASLR makes it significantly harder to exploit, not impossible if we could get some general performance numbers that show non-PIE vs PIE, that'd help make the case for turning PIE on by default regardless

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

I've just been informed that RHEL does not allow non-PIE executables. We really should follow suit here.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On Fri, Jan 27, 2012 at 20:39, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: The most common argument against it is performance loss I think, and there are probably less than 10 packages that have some compilation issues with PIE. In my opinion we can deal with that, and security benefits are

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On Fri, Jan 27, 2012 at 20:43, Mike Frysinger vap...@gentoo.org wrote: a QA warning doesn't help anyone if we don't have documentation in place explaining to people how to do this cleanly This is very true. @Flameeyes: Could you advise on the best, cleanest way to do this? What should the

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On Fri, Jan 27, 2012 at 21:13, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Again - only if we don't get a consensus here. Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID binaries*?

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On Sat, Jan 28, 2012 at 01:01, Anthony G. Basile bluen...@gentoo.orgwrote: Exactly. Jason, if you want PIE across the board (with a few exceptions), switch to hardened. What? Are you kidding? Again, to reiterate, *I AM NOT SUGGESTING HAVING PIE ACROSS THE BOARD.* What I suggest is that we

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On Sat, Jan 28, 2012 at 01:12, Mike Frysinger vap...@gentoo.org wrote: Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID binaries*? he was talking system wide This thread is about PIE on SUID executables. considering the number set*id binaries in the tree, and

Re: [gentoo-dev] Opinion against /usr merge

On Wed, Jul 18, 2012 at 1:07 AM, Olivier Crête tes...@gentoo.org wrote: Also be ready for a merge of /bin and /sbin.. I'm sure most people can't even explain the difference between them. Whoa hey what why? Who's pushing this forward?

Re: [gentoo-dev] Opinion against /usr merge

On Wed, Jul 18, 2012 at 5:35 PM, Walter Dnes waltd...@waltdnes.org wrote: 3. More support for mdev; e.g. https://wiki.gentoo.org/wiki/Mdev and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB The next challenge is custom mdev rules, which should be do-able.

[gentoo-dev] Global Systemd USE Flag

Hi, Sorry if this has been discussed to death, but I couldn't find any definitive decisions on it, so I thought I'd mention things in a fairly simple manner: Step 1: I use OpenRC/sysvinit. Dell ~ # readlink -f /proc/1/exe /sbin/init Dell ~ # equery b /sbin/init * Searching for /sbin/init ...

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:15 PM, Michał Górny mgo...@gentoo.org wrote: INSTALL_MASK=/usr/lib/systemd And live happy to the day you notice your system no longer boots. This is a nice bandaid, and sure, it solves the immediate issue... but it doesn't actually solve the actual issue: when packages

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:15 PM, Michał Górny mgo...@gentoo.org wrote: INSTALL_MASK=/usr/lib/systemd As an unrelated side note, in case any one on the internet finds this thread trying to solve this issue, it's worth pointing out that since udev now installs that directory, the INSTALL_MASK

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:31 PM, Patrick Lauer patr...@gentoo.org wrote: And as long as our maintainers refuse to use the proper paths this is just one of the little things that makes life more exciting for us. Can we please add some sanity back? Exactly. Right now, with no USE flag, and no

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:33 PM, Michał Górny mgo...@gentoo.org wrote: You are right. In case users really intend to use that, they may be better using app-portage/install-mask, and: $ install-mask -a systemd which will add just the right path. Still misses the point. USE flags were invented

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:36 PM, Michał Górny mgo...@gentoo.org wrote: We aren't going to add USE flags which don't do anything. That topic was discussed a thousand times, and rising it once more won't change our decision. Similarly, bash-completion flag will be gone at some point. Everyone

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:45 PM, Michał Górny mgo...@gentoo.org wrote: Not everyone uses bash. Not everyone cares at all about bash-completion. What is your point? I'm not saying I agree with the removal of bash-completion flag (that discussion is for elsewhere), but just that your analogy

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:48 PM, Patrick Lauer patr...@gentoo.org wrote: can we *please* use the openrc useflag to have correct paths and binary names again? Just because upstream says we should be fedora doesn't mean we have to do it. Right now it's really frustrating to have systemd

Re: [gentoo-dev] Questions about SystemD and OpenRC

On Tue, Aug 7, 2012 at 3:17 PM, Rich Freeman ri...@gentoo.org wrote: You'd have to talk to them, but I believe their goal is to go for more of a vertically-integrated experience (which fits more with Gnome or KDE than Xfce, but again the last I'd heard only Gnome was going in this direction

Re: [gentoo-dev] Global Systemd USE Flag

On Thu, Aug 9, 2012 at 12:19 AM, William Hubbs willi...@gentoo.org wrote: So, I ask again. You keep complaining about insanity. What's the insanity and why should we go to all of the extra effort you want us to go to to avoid it? I think it's more of a knee-jerk reaction to this: Redhat is

Re: [gentoo-dev] Global Systemd USE Flag

On Wed, Aug 8, 2012 at 4:31 PM, Patrick Lauer patr...@gentoo.org wrote: equery f udev | grep udevd /usr/lib/systemd/systemd-udevd And as long as our maintainers refuse to use the proper paths this is just one of the little things that makes life more exciting for us. Can we please add

[gentoo-dev] OpenRC and SystemD Config File Parity

Hey everyone, This isn't a topic meant for bike shedding, but just kind of loose exploratory inquiry. I saw a bug report about adding systemd's tmpfiles.d config format support to OpenRC (accomplished) and then some discussion about adding an ebuild utility function (dotmpfiles_d) or digging up

Re: [gentoo-dev] OpenRC and SystemD Config File Parity

On Fri, Aug 17, 2012 at 7:33 AM, hero...@gentoo.org wrote: config file formats differs a lot, for OpenRC it's shell script, while for SystemD Microsoft ini/XDG Desktop Entry Specification. Sorry, just to clarify and reiterate what I said before -- I am excluding Unit files from this

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

://git.zx2c4.com/linux/commit/drivers/base/firmware_class.c?id=abb139e75c2cdbb955e840d6331cb5863e409d0e -- Jason A. Donenfeld Gentoo Linux Security zx...@gentoo.org www.zx2c4.com

[gentoo-dev] mbox -- looks sort of interesting

evolution and whatnot. I haven't looked at this tool past an initial glance, but it does look like interesting food for thought. Jason -- Jason A. Donenfeld Gentoo Linux Security Infrastructure zx...@gentoo.org www.zx2c4.com

Re: [gentoo-dev] mbox -- looks sort of interesting

On Tue, Feb 11, 2014 at 10:39 PM, Wulf C. Krueger w...@mailstation.de wrote: On 11.02.2014 01:36, Jason A. Donenfeld wrote: It's a sandbox that uses a combination of ptrace and seccomp bpf; neither ours nor exherbo's uses both of these together. Actually, sydbox, Exherbo's sandbox *does* use

Re: [gentoo-dev] Should we allow picture files in the Portage tree?

On Thu, Feb 13, 2014 at 4:12 PM, Ulrich Mueller u...@gentoo.org wrote: Should we allow pictures if the image file format is a text file? I think we should not. Even if you can open it in a text editor, you can't read it or interact with it in the same way that you can a text-based patch. For

[gentoo-dev] Call to Emacs Gentoo Devs: Help Make My Package Pretty?

thing with the emacs stuff? It would be most appreciated. Thanks, Jason -- Jason A. Donenfeld Gentoo Linux Security Infrastructure zx...@gentoo.org www.zx2c4.com zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc

Re: [gentoo-dev] ffmpeg vs libav choice of default

On Wed, Feb 4, 2015 at 10:21 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-02-04, o godz. 10:12:12 Ulrich Mueller u...@gentoo.org napisał(a): So can someone please remind me what are the technical reasons why we prefer libav over ffmpeg? We have a developer inside I think it's

Re: [gentoo-dev] ffmpeg vs libav choice of default

On Wed, Feb 4, 2015 at 10:55 AM, Michał Górny mgo...@gentoo.org wrote: From what I heard, that upstream likes to change its opinion frequently, pretty much based on which upstream he is pissed at the moment. But it's just rumors. This is most certainly untrue. Please stop disseminating FUD

Re: [gentoo-dev] ffmpeg vs libav choice of default

On Wed, Feb 4, 2015 at 10:24 AM, Ben de Groot yng...@gentoo.org wrote: From an upstream that I care about: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav Based on that I would say we should switch back the default to ffmpeg. I can vouch for the content of that link and the

Re: [gentoo-dev] ffmpeg vs libav choice of default

Welp, the votes clearly show ffmpeg is desired by users. Can we stop this nonsense and just do that? The people have spoken. Ffmpeg shall be default.

Re: [gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

If you want ffmpeg-ish features, at all, USE=ffmpeg. If you'd like to use the libav implementation, USE=libav. If you'd prefer to use the original ffmpeg implementation, USE=-libav. This is simple. Why can't we just stick with this?

Re: [gentoo-dev] ffmpeg vs libav choice of default

I'd like to insert, early on in this thread, that we must leave personal biases and associations *out* of this discussion, and instead focus on technical merits and analyses only. Thus, I would *strongly encourage* that authors of libav and ffmpeg will *refrain from joining this discussion* in

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

ebuilds/gentoo.git or ebuilds/gentoo-main.git Namespacing things in ebuilds/ might be convenient in the future if we pursue other types of official ebuild repositories. Calling it gentoo makes sense, because the entire tree is what makes gentoo. But since it's namespaced in ebuilds/ and

[gentoo-dev] Gentoo GPG Key

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, The key I use for personal things is: AB99 42E6 D4A4 CFC3 4126 20A7 49FC 7012 A5DE 03AE The key I will now be using for Gentoo is: A28B EDE0 8F17 44E1 6037 5148 06C4 5367 5575 8000

Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?

If qt5 is set as a USE flag, it should be preferred over a qt4 USE flag. The use explicitly opted in. Also, most software that does run with Qt5 runs better with Qt5, and supports numerous features such as better HighDPI support.

[gentoo-dev] Security Auditing Services from the Gentoo Security Project

accessible to folks. If you're vaguely unsure of something, or you'd like us to look at a project that you feel deserves some security priority, shoot us an email. Hope to hear from y'all soon. Jason [1] https://wiki.gentoo.org/wiki/Project:Auditing -- Jason A. Donenfeld Gentoo Linux Security zx

Re: [gentoo-dev] RFC: app-eselect category

Yes, +1 On Mar 29, 2015 12:59 AM, Ben de Groot yng...@gentoo.org wrote: On 29 March 2015 at 04:47, Ulrich Mueller u...@gentoo.org wrote: Now the number of eselect-* packages in the app-admin category has grown to 52. Should we create a new app-eselect category for them? I think this is a

Re: [gentoo-dev] libressl status

Solution: Packages that will compile against either one get || (openssl libressl). Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa. The result of this arrangement is that systems that require few packages will probably be able to

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

This seems quite reasonable, and I welcome QA's efforts at maintaining uniformity and cleanliness. +1 On Aug 20, 2015 7:43 PM, Michał Górny mgo...@gentoo.org wrote: Hi, Right now, a number of game packages are using USE=dedicated to control 'installing a dedicated game server only'. Aside to

Re: [gentoo-dev] RFC News item: FFmpeg default

https://lwn.net/Articles/650816/ On Apr 16, 2015 1:51 PM, Ben de Groot yng...@gentoo.org wrote: On 11 April 2015 at 15:19, Ben de Groot yng...@gentoo.org wrote: And since this is now on the Council's agenda, we're waiting for their decision. Since the Council had no objections, this has

Re: [gentoo-dev] Revise EAPI 6? (was: [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability)

I'd be in favor of full-on LC_ALL=C. Ebuilds are meant for having a particular determinism. They're machine scripts. The operations they do need to be consistent. For user-facing parts, such as printing information, or sorting user-shown text, I can understand ebuild authors might want in some

[gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

Hey Ulrich, I may be a bit late to the discussion, and perhaps I should really just be reviewing mailing list posts from years past, but... What's the story of eapply? Why does this need to go into the PMS, and not continue to be supplied by epatch from the eclass? What is gained from moving it

[gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On Sat, Oct 17, 2015 at 2:19 PM, Jason A. Donenfeld <zx...@gentoo.org> wrote: > > > The other question is more critical -- could you merge eapply and > eapply_user? Or add some hook to PMS so that eapply_user isn't needed? IOW, > it'd be nice if every package was, by default,

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

On Mon, Oct 5, 2015 at 8:45 PM, Paweł Hajdan, Jr. wrote: > Curious, can one reasonably easy downgrade from GCC 5 back to GCC 4? > I've gone 4->5, urg I don't want 5, 5->4, okay it works, hey wait I want 5, 4->5. Things went fine.

Re: [gentoo-dev] LibreSSL switch-over progress

Perfect. Exactly the information I was looking for. Thanks a bunch.

[gentoo-dev] LibreSSL switch-over progress

post when it's all done? This would probably be quite nice for users too. In fact, I wouldn't mind a portage news item about this. Jason -- Jason A. Donenfeld Gentoo Linux Security & Infrastructure zx...@gentoo.org www.zx2c4.com zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

Work on making 3.1.x stable. In the mean time, mask system-ffmpeg.

[gentoo-dev] Step on my toes, please.

there mine is. Moving forward, we can come up with a more formal solution for this. I'LL START A NEW THREAD FOR THAT; DON'T REPLY HERE ON THAT TOPIC. Thanks, Jason -- Jason A. Donenfeld Gentoo Linux Security & Infrastructure zx...@gentoo.org www.zx2c4.com zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc

[gentoo-dev] Optimizing toe stepping

y.txt idea (see other thread). A few have proposed in the past adding this kind of "attitude information" to metadata.xml. Does anybody have any concrete proposals for what this would look like? Thanks, Jason -- Jason A. Donenfeld Gentoo Linux Security & Infrastructure zx...@gentoo

Re: [gentoo-dev] Optimizing toe stepping

On Thu, Nov 3, 2016 at 1:15 PM, Nick Vinson wrote: > Just doing that one little thing would have prevented or shutdown the > arguments I have seen. Yes, obviously of course. But sometimes it's just easier and quicker to meddle in somebody else's ebuild to improve a

Re: [gentoo-dev] Re: new package category: net-vpn

On Fri, Mar 17, 2017 at 4:05 PM, Michał Górny <mgo...@gentoo.org> wrote: > On pią, 2017-03-17 at 14:57 +0100, Jason A. Donenfeld wrote: >> Done. > > It's nice that you waited for people to actually wake up around > the world to give you feedback. Yep, sorry. Already

[gentoo-dev] new package category: net-vpn

Hey folks, While VPNs weren't stylish back when most categories were added to our portage tree, they now are hot potatoes. Most VPN-related programs currently live in net-misc, which isn't quite right. If nobody voices reasonable objections, I plan on adding a net-vpn category soon and moving

[gentoo-dev] Re: new package category: net-vpn

Done. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7f68c86d93d5f69d775bceb3941b3a3b46672eb1

Re: [gentoo-dev] new package category: net-vpn

Hello M. J., Your message went straight into spam, so I did not receive it before making the commit, when somebody on IRC pointed out your message. I'd encourage you to make sure your DKIM/DMARC/SPF configuration is working. Here are the packages I moved: badvpn freelan ipsec-tools kvpnc

[gentoo-dev] Removal of rxvt

any actions.) Regards, Jason -- Jason A. Donenfeld Gentoo Linux Security zx...@gentoo.org www.zx2c4.com zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc

Re: [gentoo-dev] last rites: app-text/acroread

RIP acroread. The only PDF reader on linux that can properly parse PDF Reference XObjects. Thou shall be missed.

[gentoo-dev] Manifesto for Gentoo Council 2017

Hi folks, I've published a "manifesto" for this year's council election: http://dev.gentoo.org/~zx2c4/council-manifesto-2017.txt I'd be honored and delighted to have your vote. Regards, Jason -- Jason A. Donenfeld Gentoo Linux Security & Infrastructure zx...@gentoo.org www.zx2c4

Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

On Mon, Jun 26, 2017 at 9:30 AM, Alice Ferrazzi wrote: > > Linus Torvald on grsecurity: > https://www.spinics.net/lists/kernel/msg2540934.html Spender responds: http://www.openwall.com/lists/oss-security/2017/06/24/1 Popcorn worthy thread.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

On Mon, May 29, 2017 at 5:33 PM, Michał Górny wrote: > > Secondly, it might be reasonable to provide configurable priorities for > solving multi-flag constraints. For example, we could use rightmost- > preferred logic for package.use, e.g.: > > */* PROVIDER_SSL:

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

Blake2 is in coreutils already, provides an excellent security margin, and is considerably faster than both sha2 and sha3. On Oct 19, 2017 21:09, "Michał Górny" wrote: > Hi, everyone. > > The previous discussion on Manifest2 hashes pretty much died away > pending fixes to

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 6:58 PM Michał Górny wrote: > - Have verification use a keyring of all Gentoo developers, with a > > manual prompt to add new Gentoo developers to it. > > How are you going to distribute this keyring, and how are you going to > protect attacker from injecting malicious key

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 6:55 PM Rich Freeman wrote: > You might want to read what I wrote then, because I proposed options > for using the git signatures over rsync, as well as for with git > syncing > having a tool that extracts the git > signatures and stores the metadata in the repo (ideally

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 7:48 PM Hanno Böck wrote: > Hi, Oh, thank you for arriving! I've been trying to ping you the last few days hoping you'd pop in here. :) > Something like this was I believe the original idea behind signed > manifests. Not sure how long ago this was, but we used to sign

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 7:44 PM Mariusz Ceier wrote: > I wonder how would the local changes to ebuilds be handled ? > Currently it's possible to change ebuild, do "ebuild package.ebuild > manifest" and emerge package - will this still be supported ? My proposal is to fit in at the layer of

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 7:23 PM Matthias Maier wrote: > stores tree snapshots (and not differences). So all you need is exactly > one signed commit to verify that > > - this is the full repository tree the developer saw at the time of the >commit > - this is the full history the developer

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 7:21 PM Michał Górny wrote: > > W dniu pon, 02.07.2018 o godzinie 19∶01 +0200, użytkownik Jason A. > Donenfeld napisał: > > On Mon, Jul 2, 2018 at 6:58 PM Michał Górny wrote: > > > - Have verification use a keyring of all Gentoo developers, with

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 7:57 PM Rich Freeman wrote: > This only helps you if a dev you don't trust is compromised. If a dev > you trust is compromised, they can modify anything in the tree and > you're hosed. Yes indeed. This is more or less what we're aiming for. Putting the trust in

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman wrote: > To be fair, this is relying quite a bit on the last dev doing a commit > to be checking his own tree, though that would certainly be helped if > repoman/portage/etc were checking git sigs so that the starting tree > is more likely to be clean.

[gentoo-dev] Trustless Infrastructure

Hey guys, While our infrastructure team has some nice technical competence, the recent disaster and ongoing embarrassing aftermath has made ever more urgent the need to have end-to-end signatures between developers and users. While the infrastructure team seems fairly impressive at deploying

Re: [gentoo-dev] Trustless Infrastructure

Hello Rich, There's a lot of text there, and rather than trying to parse all of that, I'll just reiterate a primary important design goal that might be overlooked: - End to end signatures from the developer to the user. This means that no matter the operation infra does before shipping it out

Re: [gentoo-dev] Trustless Infrastructure

On Mon, Jul 2, 2018 at 6:02 PM R0b0t1 wrote: > Signed hashes should be faster, no? Each directory with files could > have a manifest. Signatures work over hashes of data, anyway. I think what you're wondering, though, is the granularity of each signature? I'd recommend this be done on the

Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution

You might want to mention that alternatively, uninstalling openrc on a systemd profile system is fine to do these days, despite the warning.

[gentoo-dev] unsanctioned python 2.7 crusade

Hi, Aaron has marked tons of important and useful Python 2.7 packages for removal: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb5768cc6f38ac There are quite a few useful packages in here. Can we not do this prematurely? I've revered this commit until such a

Re: [gentoo-dev] unsanctioned python 2.7 crusade

On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman wrote: > > On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld wrote: > > > > Hi, > > > > Aaron has marked tons of important and useful Python 2.7 packages for > > removal: > > > > Can we not do

[gentoo-dev] non conflicting libressl?

Hey, For a long time now, OpenSMTPD stopped supporting OpenSSL, only supporting LibreSSL. For that reason Gentoo's opensmtpd ebuild is stuck on the 6.0 version. I'm not happy about this. It looks like other distros solve this by allowing libressl to install its libraries to /usr/lib/libressl or

[gentoo-dev] [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

A user reported that when compiling modules for a system with a 64-bit kernel and a 32-bit userland, there were linker errors. This patch here is an attempt to fix that by making sure that we always use the kernel ABI when giving target build parameters. Signed-off-by: Jason A. Donenfeld Fixes

[gentoo-dev] [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

A user reported that when compiling modules for a system with a 64-bit kernel and a 32-bit userland, there were linker errors. This patch here is an attempt to fix that by making sure that we always use the kernel ABI when giving target build parameters. Signed-off-by: Jason A. Donenfeld Fixes

Re: [gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

On Sat, Jan 4, 2020 at 9:33 PM Aaron Bauman wrote: > > On Sat, Jan 04, 2020 at 09:11:01PM -0500, Jason A. Donenfeld wrote: > > Hi, > > > > I'd appreciate some code review of this before I commit. > > > > Thanks, > > Jason > > > > Silence is c

[gentoo-dev] Re: [PATCH] linux-mod.eclass: pass proper arch to kernel's build system

Hi, I'd appreciate some code review of this before I commit. Thanks, Jason

[gentoo-dev] [PATCH] dev-python/booleanOperations: add proper dependency

Otherwise we incur breakage. Closes: https://bugs.gentoo.org/712212 Package-Manager: Portage-2.3.93, Repoman-2.3.20 Signed-off-by: Jason A. Donenfeld --- Not my package, so emailing to you/the list to apply it. Python people are usually kind of touchy about non-maintainers twiddling around

Re: [gentoo-dev] News item v2: Multiple root kernel command-line arguments

This really should have a Display-If.

[gentoo-dev] last rites: virtual/wireguard

Don't worry; WireGuard isn't going anywhere. The "virtual/wireguard" package was added mostly as a mistake a long time ago, was never intended to be an actual virtual, and has been in packages.deprecated for 8 months now, with large ewarns on every install. It's time to actually get rid of it

Re: [gentoo-dev] Last rites: dev-util/coccigrep, dev-util/coccinelle

But these are very useful tools...

[gentoo-dev] coordination on JetBrains IDEs?

Hi, mpagano maintains idea. zlogene maintains pycharm. perfinion maintains android studio. christian proxy-maintains clion. I maintain goland. These are all JetBrains IDEs that all basically follow the same format. I wonder if we can unify these somehow? Anyone interested in working on that or

[gentoo-dev] [RFC] News Item: OAuth2 Credentials Removed from Chromium

Title: OAuth2 Credentials Removed from Chromium Author: Jason A. Donenfeld Posted: 2021-08-08 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: www-client/chromium In March of this year, Google announced that OAuth2 credentials would be revoked for distros shipping Chromium

[gentoo-dev] Re: [RFC] News Item: OAuth2 Credentials Removed from Chromium

v2 after brief IRC discussion --- Title: OAuth2 Credentials Removed from Chromium Author: Jason A. Donenfeld Posted: 2021-08-08 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: www-client/chromium In March of this year, Google announced that OAuth2 credentials would be revoked for distros

Re: [gentoo-dev] Re: [RFC] News Item: OAuth2 Credentials Removed from Chromium

Thanks for the feedback. v3 is below. -- Title: OAuth2 Credentials Removed from Chromium Author: Jason A. Donenfeld Posted: 2021-08-11 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: www-client/chromium In March of this year, Google announced that OAuth2 credentials would be revoked

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

On Mon, Sep 27, 2021 at 11:44 AM Robin H. Johnson wrote: > I think we need to strip out a lot of the crap about trying to detect > things in the stuff being built, and reduce the check to the simplest > possible form: > $ time zgrep -w CONFIG_PACKET /proc/config.gz > CONFIG_PACKET=y The results

[gentoo-dev] proposal: use only one hash function in manifest files

Hi, I'd like to propose the following for portage: - Only support one "secure" hash function (such as sha2, sha3, blake2, etc) - Only generate and parse one hash function in Manifest files - Remove support for multiple hash functions In other words, what are we actually getting by having _both_

[gentoo-dev] Re: proposal: use only one hash function in manifest files

To move things forward with something more concrete: On 4/5/22, Jason A. Donenfeld wrote: > Hi, > > I'd like to propose the following for portage: > > - Only support one "secure" hash function (such as sha2, sha3, blake2, etc) > - Only generate and parse one has

  1   2   >