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

2020-08-07 Thread Jason A. Donenfeld
This really should have a Display-If.



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

2020-08-06 Thread Jason A. Donenfeld
But these are very useful tools...



[gentoo-dev] last rites: virtual/wireguard

2020-07-31 Thread Jason A. Donenfeld
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 once and for all.

The right way to install WireGuard is just `emerge wireguard-tools`,
and maybe if you're running an ancient kernel also use `emerge
wireguard-modules`.

So this is an announcement for a quick last riting of
virtual/wireguard, which was meant to sail away a long time ago.



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

2020-03-13 Thread Jason A. Donenfeld
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.

 dev-python/booleanOperations/booleanOperations-0.9.0.ebuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild 
b/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild
index 0468e6dc92f..8d822fcc410 100644
--- a/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild
+++ b/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild
@@ -20,6 +20,7 @@ BDEPEND=""
 RDEPEND="${DEPEND}
>=dev-python/fonttools-4.0.2[${PYTHON_USEDEP}]
>=dev-python/pyclipper-1.1.0[${PYTHON_USEDEP}]
+   dev-python/wheel[${PYTHON_USEDEP}]
 "
 
 src_prepare() {
-- 
2.25.1




[gentoo-dev] non conflicting libressl?

2020-01-29 Thread Jason A. Donenfeld
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 similar, so that they can
coexist with openssl, allowing programs like OpenSMTPD.

Any libressl developers interested in this sort of thing?

Jason



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

2020-01-04 Thread Jason A. Donenfeld
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 consent.

Maybe. But there's quite a bit of this that I look at and think,
"that's not necessary, let me just trim this all down to something
much smaller..." And then I start to wonder whether the original
authors have already been through several bug-fixing cycles when they
added all that. So I'd like to avoid repeating that exercise if
possible.



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

2020-01-04 Thread Jason A. Donenfeld
Hi,

I'd appreciate some code review of this before I commit.

Thanks,
Jason



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

2020-01-03 Thread Jason A. Donenfeld
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: https://bugs.gentoo.org/704468
Cc: joakim.tjernl...@infinera.com
Cc: ker...@gentoo.org
---
 eclass/linux-mod.eclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b6dc2c84d09..60b0d88e9b9 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -671,13 +671,16 @@ linux-mod_src_compile() {
# spaces that must be preserved. If don't do this, then 
the stuff
# inside the variables gets used as targets for Make, 
which then
# fails.
-   eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \
-   CROSS_COMPILE=${CHOST}- \
-   LDFLAGS=\"$(get_abi_LDFLAGS)\" \
+   local KERNEL_CHOST="$(ABI=${KERNEL_ABI} get_abi_CHOST)"
+   local KERNEL_LDFLAGS="$(ABI=${KERNEL_ABI} 
get_abi_LDFLAGS)"
+   local HOST_CC="$(tc-getBUILD_CC)"
+   eval "emake HOSTCC=\"${HOST_CC}\" \
+   CROSS_COMPILE=${KERNEL_CHOST}- \
+   LDFLAGS=\"${KERNEL_LDFLAGS}\" \
${BUILD_FIXES} \
${BUILD_PARAMS} \
${BUILD_TARGETS} " \
-   || die "Unable to emake 
HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" 
${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}"
+   || die "Unable to emake HOSTCC="${HOST_CC}" 
CROSS_COMPILE=${KERNEL_CHOST}- LDFLAGS="${KERNEL_LDFLAGS}" ${BUILD_FIXES} 
${BUILD_PARAMS} ${BUILD_TARGETS}"
cd "${OLDPWD}"
touch "${srcdir}"/.built
fi
-- 
2.24.1




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

2020-01-03 Thread Jason A. Donenfeld
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: https://bugs.gentoo.org/704468
Cc: joakim.tjernl...@infinera.com
Cc: ker...@gentoo.org
---
This is untested on the bug reporter's system, and I'd appreciate some
review from an author of this eclass.

 eclass/linux-mod.eclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b6dc2c84d09..ecfce72a142 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -671,13 +671,16 @@ linux-mod_src_compile() {
# spaces that must be preserved. If don't do this, then 
the stuff
# inside the variables gets used as targets for Make, 
which then
# fails.
-   eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \
-   CROSS_COMPILE=${CHOST}- \
-   LDFLAGS=\"$(get_abi_LDFLAGS)\" \
+   local KERNEL_CHOST="$(ABI=${KERNEL_ABI} get_abi_CHOST)"
+   local KERNEL_LDFLAGS="$(ABI=${KERNEL_ABI} 
get_abi_LDFLAGS)"
+   local HOST_CC="$(tc-getHOST_CC)"
+   eval "emake HOSTCC=\"${HOST_CC}\" \
+   CROSS_COMPILE=${KERNEL_CHOST}- \
+   LDFLAGS=\"${KERNEL_LDFLAGS}\" \
${BUILD_FIXES} \
${BUILD_PARAMS} \
${BUILD_TARGETS} " \
-   || die "Unable to emake 
HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" 
${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}"
+   || die "Unable to emake HOSTCC="${HOST_CC}" 
CROSS_COMPILE=${KERNEL_CHOST}- LDFLAGS="${KERNEL_LDFLAGS}" ${BUILD_FIXES} 
${BUILD_PARAMS} ${BUILD_TARGETS}"
cd "${OLDPWD}"
touch "${srcdir}"/.built
fi
-- 
2.24.1




Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Jason A. Donenfeld
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 this prematurely? I've revered this commit until such a
> > thing an be appropriately agreed upon.
>
> Might make sense to wait to mask them at the same time as masking
> python 2.7 itself?  Maybe file a bug if not already done to make
> maintainers aware that this is coming?
>
> I assume the python team is the one deciding when python 2.7 has to go
> (after all, who else is going to maintain it?).  The fact that this is
> about a month off did come up in another recent thread but I don't
> think it was intended as a formal announcement.

It's one thing to mask python libraries in general. If gentoo isn't
going to support 2.7, then those libraries don't make sense to  keep
around.

It's quite another to mask random packages that have USE flags to
optionally support whatever python 2.7 library. If you're going to
last rites these, talk with the maintainer first, and only then, send
emails one at a time. Doing that en masse isn't appropriate.

On another topic, I'd prefer for python 2.7 not to be removed from
gentoo. Tons of code still uses it.



[gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Jason A. Donenfeld
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
thing an be appropriately agreed upon. Many of those packages are
actively maintained upstream packages. abcde, beets, and tahoe-lafs
immediately jump out.

Thanks,
Jason



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 developers. The goal is for infra not to be the weak link in
this, as it currently is.

> Sure, I'd prefer to not extract git signatures and just distribute via
> git purely without any rsync.

Yea, I personally don't really care much for rsync either. I've just
kind of been assuming this is a requirement of any gentoo solution.
But maybe this whole thing should take another dimension, and we
should instead talk about sunsetting rsync, and moving to a model of:
1) git fetch, 2) git verify, 3) git checkout? There still might be
problems with "untrusting" devs, as I wrote above, but perhaps there's
room to grow within the git framework, by manually filtering commits
during checkout, or even by imposing ebuild directory signature-based
ACLs that I think you were hinting at before. So, sure, if you want to
call for an abolition of rsync, maybe I'd follow you in that direction
instead of the one here I'm proposing.


>
> Sure, but since any developer can change any file, that is basically
> the same thing.  If somebody steals a single dev's key they can just
> rootkit any file of their choosing, sign that one change, and it will
> slip through any of these methods.  The only protection against that
> is tracking who is allowed to touch what files, and then you're still
> hosed if a dev for a widely-used file gets their key stolen.

As stated above, yes, this is the intended model. And I think it's
considerably better than the current state of affairs. The threats get
even less scary as we convince Nitrokey or Yubikey to send all gentoo
developers free devices, and then mandate keys remain on those devices
and never get copied, etc etc.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 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 into it?
> >
> > Same model as Arch.
> >
>
> Please write it down here instead of expecting us to figure it out.
> It's your proposal, and it should be complete.

I believe Arch's system relies on some core developers having master
keys and the revocation certificates being distributed amongst them:

https://www.archlinux.org/master-keys/

Then all other developers are signed from there in one way or another.
It's kind of a modified web of trust.

I don't know whether or not this is necessarily the best model to
emulate -- perhaps we could do better, for example -- but it does seem
like a good starting point. Instead we might prefer a single hardware
device somewhere.

The idea would be -- portage fetches an updated "key list" from
somewhere. This new list of keys is considered if it is: a) signed by
the master keys and b) internally fulfills some WoT topological
requirements. Then, if these pass, it is up to the user to then
manually [y/N] the addition of new keys to the key ring. If they
suspect a particular developer has bad security practices, for
example, they could trivially [N] it, and then not have tree files he
touched copied from the shadow location to the portage directory.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 Manifest
> files at some point, though it never was part of any consistent concept
> as far as I know, and they weren't checked regularly.

Right, but I believe the manifest signatures had some limitations,
with eclasses and with overly broad granularity. Whereas adding a .asc
for each individual file as it's edited is really quite simple.

> Anything like this comes with some obvious problems that you need to
> answer if you want to have such a system:
> * How are you keeping the keys up to date? Which keys are included
>   there? All currently active developers? All active and former
>   developers?
> * What happens if a key expires? Do you accept expired signatures if
>   the package has been committed before the expiration date? Or is
>   there some kind of resign process if that happens? Does the developer
>   have to do this himself or can other developers do this? If it's up
>   on the developer what happens if he's inactive / on long holiday /
>   not reachable when his key expires?
> * What happens if a key is revoked, because a developer decides to
>   create a new key? Same question as with expired keys: Do all
>   signatures need to be recreated? How's that going to happen?
> * What happens if a developer leaves Gentoo? We'll still want to have
>   his packages. Again a resign procedure?
>
> I don't want to say this is unworkable. But these are challenges and
> imho fixing them all is really, really tricky. Either you break stuff
> regularly or you have procedures that someone has to do regularly in
> order to avoid breakage (more work for gentoo devs) or you expand the
> scope of accepted signatures very excessively.

I think the answer to these questions is to start out fairly
restrictive and see how it goes and what sorts of easing is needed in
practice. For example, it might work fine to let keys expire, to let
developers retire and have their keys removed, and so forth, and
simply have some nice monitoring infrastructure and alert tools
(repoman full, for example) so that some developer somewhere re-ups
the signature after taking a glance.

Jason



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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.  Also, if the last dev's key is
> compromised you're hosed no matter what as they can introduce anything
> to the tree and everybody will trust it.

Actually, no. By keeping a local keychain of trusted developer keys --
Arch Linux style -- you can just remove developers you don't trust,
and since the .asc files they signed will no longer verify, files from
them will no longer be copied into the real portage tree. It's a nice
way to make the entire process granular, yet still flexible.

> The original point zx2c4 is making is reasonably valid.  IMO it is
> much cleaner to just verify directly against the git history.  If you
> wanted to verify the whole git history via rsync you're going to have
> to extract a lot more metadata from the git repo to reconstruct all of
> that down to the blobs, because otherwise the commit content hashes
> are referring to blobs that are no longer in the rsync tree.

This kind of git-signature extraction also just sounds difficult and
fiddly to do, even if you do manage to figure out which partial bits
of metadata you need for reconstructing signed hashes. Whereas simply
adding .asc files is a single invocation of GPG -- a pretty
well-understood non fancy procedure.

> I think a big question here is whether we just need to test the last
> dev's commit for normal user use.  If so, then that simplifies things
> a lot, either for rsync or git syncing.  If you want to test all the
> prior history then the rsync solution gets more complex if you want to
> leverage git sigs.  However, I'd argue that with our current trust
> model the entire history is only as good as the last dev's commit
> anyway.  Maybe if devs had a more limited scope of authority that a
> verification tool could take into account you'd get more from looking
> backwards in time (it would reject a commit to openrc by an X11 dev,
> as an example).

I think you assessment of the situation here is incorrect. It's not
necessary to trust a developer for the entire state of the tree. You
only need to trust (or distrust) a developer for the files he's
changed.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 sync'ing -- so that only
files that verify get merged into the real portage tree. This,
therefore, wouldn't interfere with anything else you felt inclined to
stick in the portage tree yourself.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 saw at the time of the commit

I'm not sure this is as good, though. I don't think all developers
verify the whole tree before adding a signature on top. And this
leaves out file-level granularity, so I can't choose to distrust a
certain set of developers I know to have poor security practices and
have .asc files from those developers simply not verify. With the
extracted-git model, it winds up being "the most recent developer
signs everything for everybody". This is a bit weaker than what I've
proposed.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 into it?

Same model as Arch.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 done by infra
> before mirroring, but it could be done after the fact as well)

Aren't git signatures done over the full commit objects? Meaning you'd
need the entire tree of metadata and thus all commits in order to
verify? Or do you see some clever opportunity for extracting just
enough metadata that you could actually have a file-based, rather than
commit-based, verification?



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 per-file level, since we wouldn't want gentoo devs
signing files in a directory they haven't actually inspected. For
example, eclasses.

>
> > - Ensure the naming scheme of portage files is sufficiently strict, so
> > that renaming or re-parenting signed files doesn't result in RCE. [*]
> > - Distribute said .asc files with rsync per usual.
>
> Rsync would work with this setup, but there is also webrsync-gpg in
> Portage right now. This covers the vast majority of usecases right
> now.

Not sure whether you've missed the point or if you're responding to
something slightly different, but it's worth noting that both rsync
and webrsync-gpg right now check against infra signatures, rather than
developer signatures, and this is a big problem.



Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 to the user, the user still needs to verify that the packages came
from the developers. In other words, whatever complicated mechanism
you propose, it needs to not rely on trusting infra to hold onto any
secrets. For example, I don't know whether this is attainable with the
the git signatures alone, without requiring users to sync the entire
git repository, which might not be acceptable for some.

Jason



[gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Jason A. Donenfeld
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 services and keeping the house running smoothly, I'd rather
we don't place additional burden on them to do everything they're
doing securely. Specifically, I'd like to ensure that 100% of Gentoo's
infrastructure can be hacked, yet not backdoor a single witting user
of the portage tree. Right now, as it stands, rsync distributes
signatures to users that are derived from some
infrastructure-controlled keys, not from the developers themselves.

Proposal:
- Sign every file in the portage tree so that it has a corresponding
.asc. Repoman will need support for this.
- Ensure the naming scheme of portage files is sufficiently strict, so
that renaming or re-parenting signed files doesn't result in RCE. [*]
- Distribute said .asc files with rsync per usual.
- Never rsync into the /usr/portage directory, but rather into an
unused shadow directory, and only copy files from the shadow directory
into /usr/portage after verification succeeds. (The fact that those
files are visible to portage prior to verification and following a
failed verification is a shameful oversight of the current system.)
- Have verification use a keyring of all Gentoo developers, with a
manual prompt to add new Gentoo developers to it.
- Eventually acquire (sponsors?) nitrokeys/yubikeys for all
developers, and mandate everyone stores their Gentoo key material in
there exclusively.

This is very similar to what Arch Linux is doing, and AFAIK, it works
well there. I'm sure this list will want to bikeshed over the
particulars of the implementation, but the two design goals from this
are:

- Signatures are made by developers, not by infra.
- Portage doesn't see any files that haven't yet been verified.

Regarding the [*] comment above about the directory tree. There might
be more clever ways of handling this, like having the last developer
who modified the tree compute some kind of holistic signature, in
addition to each of the individual ones. Or, perhaps, this is the one
place where we would consider relying on infrakeys, provided portage
isn't victim to clever RCE by rearrangement. Other attacks include, of
course, downgrades and DoS.

Hopefully we can move Gentoo's portage tree security up to modern
security expectations, and no longer be forced to trust vulnerable
sitting-duck infra machines for our signatures.

Jason



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

2017-12-26 Thread Jason A. Donenfeld
You might want to mention that alternatively, uninstalling
openrc on a systemd profile system is fine to do
these days, despite the warning.



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

2017-10-20 Thread Jason A. Donenfeld
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 Portage. Since Portage was fixed a while ago, and we
> can now safely switch, I'd like to reboot the discussion before
> submitting the item for the next Council meeting.
>
> Considering all arguments made so far, I'd like to propose changing:
>
>   manifest-hashes = SHA256 SHA512 WHIRLPOOL
>
> to:
>
>   manifest-hashes = SHA512 SHA3_512
>
> In other words, removing SHA256 and WHIRLPOOL, and adding SHA3_512.
>
>
> Rationale
> -
>
> 1. The main argument for using multiple hashes is to prevent the (very
> unlikely) possibility that if a weakness is discovered in one of
> the hashes, the other would still hold. This is given by using two
> algorithms; more than two do not increase security significantly, while
> they do increase performance cost.
>
> 2. For the above to hold, the hashes should be diverse. SHA256
> and SHA512 are the same algorithm, so a weakness discovered in either
> would probably apply to both -- keeping both does not make sense at all.
> Furthermore, both SHA2 and WHIRLPOOL use the same construct (MD), so
> a weakness in the construct would apply to both.
>
> 3. Keeping one of the three old hashes is necessary for compatibility
> reasons. Furthermore, the current versions of Portage consider SHA512
> obligatory, so we can't remove it without redesigning Portage first
> (though I think this applies only to developer installs, i.e. those
> creating Manifests).
>
> 4. The new hashes that are stronger and commonly available are
> SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
> our current algorithms, so either is a good candidate. The choice of
> Keccak is purely arbitrary (because it's the winner?).
>
> All the above considered, I think it's most reasonable to use two hashes
> with diverse constructs. SHA512 needs to be one of them, for
> compatibility reasons. The other could be either SHA3_512 or BLAKE2B,
> as a strong, future-proof hash. SHA3 is probably a better choice because
> it's going to have more support as the official recommendation.
>
> --
> Best regards,
> Michał Górny
>
>
>


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

2017-06-26 Thread Jason A. Donenfeld
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.



[gentoo-dev] Manifesto for Gentoo Council 2017

2017-06-20 Thread Jason A. Donenfeld
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.com
zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc



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

2017-06-09 Thread Jason A. Donenfeld
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: openssl gnutls
>   dev-util/foo PROVIDER_SSL: polarssl
>
> which would mean that for all packages, gnutls is preferred over openssl
> (i.e. if ?? or ^^ applies, openssl will be disabled and gnutls will be
> used), and polarssl is additionally preferred over everything else for
> dev-util/foo.

Please, leftmost instead of rightmost?



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

2017-06-08 Thread Jason A. Donenfeld
RIP acroread.

The only PDF reader on linux that can properly parse PDF Reference XObjects.

Thou shall be missed.



[gentoo-dev] Removal of rxvt

2017-05-11 Thread Jason A. Donenfeld
Hi folks,

Rxvt is ancient. It's been replace by rxvt-unicode. Rxvt hasn't seen
updates in years. Recently it's been the subject of a security
vulnerability, and I suspect it's filled with other potential
vulnerabilities. Rxvt has no upstream. I tried reaching out to the
former upstream, and it's evident everybody has moved on and has no
interest in further maintenance. It doesn't even have a Gentoo
maintainer!

Given this, I'd like to remove rxvt from Gentoo, with the usual
mask-for-30-days process.

Does anybody have any objections to me doing this? (I'll wait a week
from now before taking any actions.)

Regards,
Jason

-- 
Jason A. Donenfeld
Gentoo Linux Security
zx...@gentoo.org
www.zx2c4.com
zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc



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

2017-03-17 Thread Jason A. Donenfeld
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 chastised and discussed at length on IRC. Duly noted.



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

2017-03-17 Thread Jason A. Donenfeld
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
libreswan
logmein-hamachi
openconnect
openfortivpn
openvpn
peervpn
strongswan
tinc
vpnc
vpncwatch
wireguard

I did not move the various l2tp packages from net-dialup, though
perhaps this will happen later.

Jason



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

2017-03-17 Thread Jason A. Donenfeld
Done.

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



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

2017-03-16 Thread Jason A. Donenfeld
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 relevant packages into it.

Thanks,
Jason

[Note to bikeshedders: do *not* let this thread devolve into a general
discussion on "categories in general" or something terrible like
that.]



Re: [gentoo-dev] Optimizing toe stepping

2016-11-03 Thread Jason A. Donenfeld
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 particular situation. The question is thus
how do we make this permissible? My proposal is adding a metadata.xml
tag -- .

Jason



[gentoo-dev] Optimizing toe stepping

2016-11-03 Thread Jason A. Donenfeld
Hey guys,

Every other day on IRC, I see people arguing about touching each
others packages, despite our policies against it. (Sometimes it's even
me who's doing the touching!) My instinctive reaction is always,
"can't everybody calm down and be happy somebody is doing your work
for you?" The answer to this question is, of course, that it depends
who the developer is and how competent you are.

So, nothing new here. I don't want to bikeshed about it. Business as usual.

Perhaps we can come up with something more formal for solving this,
that works a bit better than my package-policy.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.org
www.zx2c4.com
zx2c4.com/keys/A28BEDE08F1744E16037514806C4536755758000.asc



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

2016-11-03 Thread Jason A. Donenfeld
Hey guys,

Every other day on IRC, I see people arguing about touching each
others packages, despite our policies against it. (Sometimes it's even
me who's doing the touching!) My instinctive reaction is always,
"can't everybody calm down and be happy somebody is doing your work
for you?" The answer to this question is, of course, that it depends
who the developer is and how competent you are.

So, nothing new here. I don't want to bikeshed about it. Business as usual.

I thought I'd do something loose and informal to rectify the problem.
See my package-policy.txt on my developer space:

http://dev.gentoo.org/~zx2c4/package-policy.txt

Do what this says, and everything will be good. I encourage other
developers to post package-policy.txt with the same URL scheme. This
is a nice loose and informal stopgap solution. If others want to
follow suit, great. If not, welp, 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



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

2016-08-29 Thread Jason A. Donenfeld
Work on making 3.1.x stable.

In the mean time, mask system-ffmpeg.


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

2015-11-11 Thread Jason A. Donenfeld
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 special
circumstances to run a command with the user's language. For that reason,
what if we did this:

USER_LANG="$LANG"
unset LANG ${!LC_*}
export LC_ALL=C

That way, ebuild writers could do:

LC_ALL="$USER_LANG" einfo "Blah blah $(sort  wrote:

> > On Wed, 11 Nov 2015, Ciaran McCreesh wrote:
>
> > On Wed, 11 Nov 2015 07:16:42 +0100
> > Patrick Lauer  wrote:
> >> Wouldn't it be 'easier' (fsov easy) to have portage use sane-default
> >> locale settings, so that estonian or turkish users don't get hit by
> >> weirdness in the [a-z] character class etc.?
>
> > Paludis forces all the LC variables to sane values. A few vocal
> > annoying users hate this, and patch it out...
>
> Unfortunately, that doesn't help us, since ebuilds cannot rely on it.
>
> Should we revise EAPI 6? It hasn't been cleared for usage in the tree
> yet, so should be still possible. Losing such an important feature of
> bash-4 seems to be reason enough. (And obviously, some people had been
> aware of the problem. Why did nobody speak up before the spec was
> approved?)
>
> Paludis seems to do this:
>
> unset LANG ${!LC_*}
> export LC_ALL=C
>
> We could just add this to the spec. Alternatively, something less
> intrusive, like setting only LC_COLLATE and LC_CTYPE.
>
> We already have LC_MESSAGES=C in the base profile, per 20130813
> Council decision.
>
> Ulrich
>


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

2015-10-17 Thread Jason A. Donenfeld
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 to PMS, and why is it more semantically correct to have it there?
Just curious about this.

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, patchable by the user.

Regards,
Jason


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

2015-10-17 Thread Jason A. Donenfeld
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, patchable by the user.
>

Looks like I answered my own question!

>From the spec:

For EAPIs listed in table 9.3 as using format 6, the default implementation
> used when the ebuild lacks the src_prepare function shall behave as:
> src_prepare() {
> if declare -p PATCHES | grep -q "^declare -a "; then
> [[ -n ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
> else
> [[ -n ${PATCHES} ]] && eapply ${PATCHES}
> fi
> eapply_user
> }


Awesome!!

This is a great change.


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

2015-10-05 Thread Jason A. Donenfeld
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

2015-10-05 Thread Jason A. Donenfeld
Perfect. Exactly the information I was looking for. Thanks a bunch.



[gentoo-dev] LibreSSL switch-over progress

2015-10-05 Thread Jason A. Donenfeld
Hi guys,

I've seen we now have a libressl USE flag, per the discussion in the
other thread. Horrah!

Last night I tried to enable that flag globally, and then reemerge
everything relevant. Unfortunately, I got some unresolvable blockers.
Presumably the reason is that some packages have the libressl USE
flag, while others don't have it. I assume there are developers hard
at work adding the flag to each and every package.

The reason for this post is: how do I know when to try switching over
again? Can the folks involved with the flagging operation agree to
make a blog post or a mailing list 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] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

2015-08-20 Thread Jason A. Donenfeld
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 that, some game
 packages also have USE=server that controls building the server itself.
 Non-game package use USE=client and USE=server.

 In order to improve uniformity of USE flags across different packages,
 the QA team would like to deprecate USE=dedicated and use USE=client
 and USE=server as appropriate.

 The problems I see with USE=dedicated are:

 - it is game-specific. The term 'dedicated server' is not used amongst
   other server/client model packages.

 - It uses negative logic. Instead of enabling something, it disables
   client. Pretty much 'dedicated' == 'noclient'. Negative logic is
   confusing.

 - In packages having USE=server as well, it can lead to really absurd
   combinations, like what does 'USE=dedicated -server' mean? Will it
   build no executables at all? If we add REQUIRED_USE='dedicated?
   ( server )', this gets quite unfriendly.

 As an alternative, we would use USE=client and USE=server along with
 proper IUSE defaults to control client  server builds appropriately.
 Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
 is rather clear.

 Does anyone see any real problems with that?

 --
 Best regards,
 Michał Górny
 http://dev.gentoo.org/~mgorny/



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

2015-07-14 Thread Jason A. Donenfeld
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 now been committed.

 Thanks for all the feedback.

 --
 Cheers,

 Ben | yngwin
 Gentoo developer




Re: [gentoo-dev] libressl status

2015-04-06 Thread Jason A. Donenfeld
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 have libressl installed, so long as all their
ssl-using apps are okay with libressl. Systems that require openssl-only
packages won't get libressl. Then, overtime, upstreams and patch writers
will gradually fill in the gaps, and eventually most packages will support
both.

This is the reasonable evolutionary approach. And it'll provide a good
ground for gradually rolling out libressl support.
On Apr 5, 2015 10:35 PM, hasufell hasuf...@gentoo.org wrote:

 On 04/05/2015 08:59 PM, Rich Freeman wrote:
  On Sun, Apr 5, 2015 at 2:35 PM, hasufell hasuf...@gentoo.org wrote:
 
  You are ranting at the wrong place. If you want to make a difference,
  take this to the openbsd mailing lists.
 
 
  It seems unlikely that this would make much of a difference.

 It doesn't make one here.

  I think
  that allowing this package to create another ffmpeg vs libav mess is a
  mistake.
 

 If you want to do some crazy downstream hackery, you'll have to do that
 yourself and count me out. It's not even clear what you want to fix.

 It was known from the start that we do not have ABI-compatibility.

 The only problem right now are libressl-exclusive features. These are
 currently optional codepaths afais, so packages still compile with openssl.

 Everything else is future prediction. That's why libressl is still in an
 overlay.




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

2015-03-28 Thread Jason A. Donenfeld
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 good idea. So +1 from me.

 --
 Cheers,

 Ben | yngwin
 Gentoo developer




[gentoo-dev] Gentoo GPG Key

2015-03-18 Thread Jason A. Donenfeld
-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

Regards,
Jason
- -BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVCZIBAAoJEEn8cBKl3gOuvkUP+wXHBXJahKhrcFAxBzRPsqQX
WY0VIG/tVQQ1B+9w3qYWNw4bKqRsuKsi8JgMOqLnzZybKVm23/sYbPoA7mInrcNX
FbPeybG+TqlUzedAVTWr2TQqJ97EvwSSEbmKqQ6jzpDCX0GhrnoIoDhMvGLm3G14
gWfrqdBPibmJcMg45lregXWbZPRO20rVcw8J5+a+aenbx+TaMic8uFcHpvX2bZ0S
4AZVDsvWLgTB5zWjvmgUdQ9tvJw7f+JIpv0yZnj55ZmGpi1B0jiWWw53NMbEOvpe
IVxZAOPOK8bNlyp0me5zUjbMq2dmC0Bfl3BuJTfYS0hRDPuQERRIo9sIRmFfjxnq
rVVaJi5T84spqGbfPM4f5wC7VojtOWtpSs8JCDP2Y15a78IF/OCSIZcm+NekwmHi
KmZI9IaKWm8pb4AZ7dXAnXj0j8CtEPbkHYz4WmhNUZ9taZ7km+yp0Hpehyi7FL1A
S/7RHb4a1whW0elvdV7IsckWDjvYCuOO4qVAOC7AF5x8FtUILSoXSt8s6s/WKo7s
F4DKJn1k2KRSdWY4cdfeDY8Wqp3zgjraIN5gsvoH4hgQAtZ+qyo1sEb5O0YPEskO
CHysHekMzYkvU7B8XvDSzhUmhQd8wcgIIAFjLtnT4L9Y/2HH6RnhicYdC7cD/mBr
y5x2dsJMISFciVpI3W3x
=EBoN
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVCZIZAAoJEA9GG/3yO0PNu4IP/36Cz+4iBGwJk8jhsx1S6VbA
AxalLZQbE1wvVlrv2S02ocqD1lweJlCGPmbLYt/GdyG97Bh8SwkJvqBtCNPm1pcm
jFjc5XAQhj2xfWFEP+G1a1SmJs/cQV6mQlE0v2MIbM4vWVQ56/ka/gdJ8cu/uBoP
IFLpO5v4ELUhD3qCZsG/PROCluWHcXfEFsANd3TIm396bAVSFWVyDZHBwehWdH+I
ozVNPseIWoGFnUEOATjWM5ot+1wUoLGsS9Wyr7CsxvGKCqJu8MqKsPppf9XYB2OX
1ZYBzvkYi43gy2E2gIoLBlJan/SMbGMAK/S5cIlGUsGDd/Z85NAB35Dz9x1MnZ6R
gvBSqYy5hF0wdzKKDN0KIULVM1gTAuA8gPpws8kdPImcKyCidBRxIeYwTWq6ATZX
QuBHWVpN/2qcKaNhbesvUx2Vx3B1rppMoAPJjtoqQNZ0XphrhM4+rt4SgbxiHstt
vYKFk5jUx3fjzVna9phVVKm4w/mYhmIsK6zEoc4JHOEbtXj0c8xFmQ/GLHOV6aNA
ii4vM3S5guQpCgSzklv/Ejzrl+5Z0SqGMwSUgwF6ZDE6mraacBDCnrJUJmQXqWoU
oBiUReX9MSMZokblWE3tg63+CGb2qmcTHL28dle7bmPlmgJOoNMyugf5ZF+q0Zy0
MOI3aStIr+AJdiJ6/6a7
=ww+E
-END PGP SIGNATURE-



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

2015-03-14 Thread Jason A. Donenfeld
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 because ebuilds/ might
have other gentoo-official repos too, then perhaps gentoo-main makes more
sense.


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

2015-03-12 Thread Jason A. Donenfeld
Hey folks,

Over on the Gentoo Security Project, we're reviving the auditing
subproject [1]. This is going to take on numerous forms, but one
important one is having an opportunity to work more closely with
Gentoo developers in general. Today we're announcing an email alias
for sending auditing requests to us. If you're working on a package,
a project, or simply have any kind of security-related concern of
suspicion, don't hesitate to sound us a casual email, and you'll have
some expert eyeballs on the case.

Security Audit Requests: security-au...@gentoo.org

We want to make this fairly 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...@gentoo.org
www.zx2c4.com
zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc



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

2015-03-09 Thread Jason A. Donenfeld
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.


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

2015-02-06 Thread Jason A. Donenfeld
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] ffmpeg vs libav choice of default

2015-02-04 Thread Jason A. Donenfeld
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 time to end this cronyism, and instead examine things on their
technical merit alone. I believe we should go with the opinion of the
upstream mpv authors, who make a very clear and compelling case for ffmpeg
as default.


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

2015-02-04 Thread Jason A. Donenfeld
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 like this.
There is zero factual basis for it.

Fortunately, the wiki history of the above linked page retains its history,
and we can quickly disprove this petty claim:
https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav/_history


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

2015-02-04 Thread Jason A. Donenfeld
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 expert opinion of its
author. As a consequence, I would high recommend switching back to ffmpeg
as default.


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

2015-02-04 Thread Jason A. Donenfeld
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
order to keep unnecessary biases out, which perhaps the sole exception of
sending stray commit sha1s along if needed. I believe previous Gentoo
policy to have been ruled by this non-technical aegis.


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

2015-02-03 Thread Jason A. Donenfeld
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?


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

2014-05-08 Thread Jason A. Donenfeld
Hey Emacs Gentoo Devs,

I maintain the app-admin/pass ebuild. Inside the contrib/emacs directory of
the tarball/gitrepo there is password-store.el and Cask (
http://git.zx2c4.com/password-store/tree/contrib/emacs).

I probably want to add an emacs USE flag that RDEPENDs on virtual/emacs,
and then does something with the aforementioned files in src_install (or
maybe src_compile too?). I see there's an elisp-install function and
something else about site functions, but truth be told, I'm a heathen vim
user, and know nothing about emacs.

Would somebody help me to make the ebuild do the right 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] Should we allow picture files in the Portage tree?

2014-02-13 Thread Jason A. Donenfeld
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 that reason, big size or small size, it still in
essence falls under the 'binary file' criteria and thus should not be
permitted.



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

2014-02-11 Thread Jason A. Donenfeld
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 both together.

I didn't know sydbox made use of bpf. That's really cool. I'll have to
take another look.



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

2014-02-10 Thread Jason A. Donenfeld
Hey folks,

Late night clicking-while-drooling, I came across something a few
minutes ago that mildly piqued my interest -- mbox
http://pdos.csail.mit.edu/mbox/. It's a sandbox that uses a
combination of ptrace and seccomp bpf; neither ours nor exherbo's uses
both of these together. The killer feature, for us, that's motivating
me to write to this list, is that it creates a shadow file system,
and then has the option to commit the changes of that file system to
the real file system, piece by piece, when the process is done. It
made me think of some discussions we had at FOSDEM about Portage
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] Sets in the tree

2013-08-14 Thread Jason A. Donenfeld
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 about
standardizing the set formats.


Re: [gentoo-dev] eselect init

2013-06-22 Thread Jason A. Donenfeld
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 of this innovation. Motivated users who want the ability to
change back and forth can emerge eselect-init and modify their init= line
in the bootloader.

This is cleaner because it keeps things more in lockstep with upstream.

This is also politically easier, as it doesn't require any notable changes
or new ebulds to openrc folks, which I can imagine might be met with
opposition here and there.


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

2013-06-10 Thread Jason A. Donenfeld
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?



[gentoo-dev] IBM License

2013-02-28 Thread Jason A. Donenfeld
Hi folks,

Over in #gentoo-dev we've been discussing the need for a new license
for OpenSMTPD (currently in my overlay [1]).

What do we call it, and should it be included, or is it already
covered by another license we have?

 * Portions Copyright (c) 1995 by International Business Machines, Inc.
 *
 * International Business Machines, Inc. (hereinafter called IBM) grants
 * permission under its copyrights to use, copy, modify, and distribute this
 * Software with or without fee, provided that the above copyright
notice and
 * all paragraphs of this notice appear in all copies, and that
the name of IBM
 * not be used in connection with the marketing of any product incorporating
 * the Software or modifications thereof, without specific, written prior
 * permission.
 *
 * To the extent it has a right to do so, IBM grants an immunity from suit
 * under its patents, if any, for the use, sale or manufacture of
products to
 * the extent that such products are used for performing Domain Name System
 * dynamic updates in TCP/IP networks by means of the Software.
No immunity is
 * granted for any product per se or for any other function of any product.
 *
 * THE SOFTWARE IS PROVIDED AS IS, AND IBM DISCLAIMS ALL WARRANTIES,
 * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
 * PARTICULAR PURPOSE.  IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL,
 * DIRECT, INDIRECT, OR CONSEQUENTIAL 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 A. Donenfeld
Gentoo Linux Security
zx...@gentoo.org
www.zx2c4.com



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

2012-11-18 Thread Jason A. Donenfeld
Hey guys,

Just read through this entire thread, and one concern still rings loud
and clear -- what is the purpose of this fork?

The various responses I've read so far are something like:

- Because Linus yelled a lot when udev/Kay broke firmware loading.

Except both Linus and the udev people fixed the problem. Linus added
direct filesystem loading in the kernel [1], and I'm told the udev
folks also fixed their hang and async situation.

- Because udev requires systemd.

Except the patches to build udev without systemd are not very large.

- Because of kmod.

Still required for things, even if its indirectly removed.

- Because we want to have separate /usr working again.

Will udev alone actually fix the separate /usr functionality? What's
required here?

Don't bother responding to the above bullet points, even if they're
garbage. Instead, read on to what I'm really after.


In general, what I'm looking for is some kind of well-written,
well-thought out mission statement, that clearly says okay here are
the issues, here's generally how we're going to solve them, and here's
why you should feel good about this being a Gentoo project.

At the moment, I haven't found anything like this, and the fact that
it's an official Gentoo project consuming the time and hearts of
intelligent developers makes me concerned, since I'm in the dark as to
its purpose and motivation.

All I'm asking is some kind of coherent mission statement. If the
aggregated responses to the bullet points above are inaccurate, don't
bother responding to those inaccuracies on a point by point basis or
bikeshed on them, or whatever happens on mailing lists. Just, please,
tell everybody what exactly you want to do, why you want to do it, and
what this is all about.

Thanks a lot,
Jason


[1] 
http://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] OpenRC and SystemD Config File Parity

2012-08-16 Thread Jason A. Donenfeld
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 something from systemd.eclass for this. This whole
discussion got me thinking --

To what degree is there parity of configuration formats between OpenRC
and SystemD? Obviously there will never be any sort of parity ever for
Unit files, but what about for the general parameters of the system?
machine-id, locale, timezone, hostname, et cetera.

I suppose when I refer to OpenRC, I'm really talking about Baselayout.

I guess more specifically what I'm wondering is:

- What is the current state of differences between config file formats
and locations used for OpenRC/Baselayout and SystemD?
- Is parity desirable? Are some people working on this?
- Are there advantages / disadvantages? Which files, for what, and why?


Anyway, if folks have opinions or thoughts, I'd love to hear them. But
this is just loose inquiry, not a pressing question for a project in
motion, so don't feel compelled to exsanguinate your soul here.

Jason



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

2012-08-16 Thread Jason A. Donenfeld
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 discussion, for obvious reasons. Unit
files are the ini files you commented there. My inquiries are directed
toward the other more global system configuration files that systemd
and openrc use. Again, the discussion is not about Unit files, ini, or
shell scripts vs systemd units; this is considered off-topic.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-12 Thread Jason A. Donenfeld
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 some sanity back?


The gods heard your call, and have replied:
 Yes, udev on non-systemd systems is in our eyes a dead end, in case you
 haven't noticed it yet. I am looking forward to the day when we can drop
 that support entirely.
-- Lennart  [1]

[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html



[gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 ...
sys-apps/sysvinit-2.88-r3 (/sbin/init)


Step 2: There are lots of systemd service files installed.

Dell ~ # ls /usr/lib/systemd/system/*.service|wc -l
21


Step 3: What on earth is installing them?

Dell ~ # equery b /usr/lib/systemd/system/*.service
media-libs/libcanberra-0.29
(/usr/lib/systemd/system/canberra-system-shutdown-reboot.service)
media-libs/libcanberra-0.29
(/usr/lib/systemd/system/canberra-system-bootup.service)
media-libs/libcanberra-0.29
(/usr/lib/systemd/system/canberra-system-shutdown.service)
media-sound/alsa-utils-1.0.25-r2 (/usr/lib/systemd/system/alsa-restore.service)
media-sound/alsa-utils-1.0.25-r2 (/usr/lib/systemd/system/alsa-store.service)
net-misc/dhcpcd-5.5.6 (/usr/lib/systemd/system/dhcpcd.service)
net-misc/openssh-6.0_p1-r1 (/usr/lib/systemd/system/sshd@.service)
net-misc/openssh-6.0_p1-r1 (/usr/lib/systemd/system/sshd.service)
net-wireless/bluez-4.101-r1 (/usr/lib/systemd/system/bluetooth.service)
net-wireless/wpa_supplicant-1.0 (/usr/lib/systemd/system/wpa_supplicant.service)
net-wireless/wpa_supplicant-1.0
(/usr/lib/systemd/system/wpa_supplicant@.service)
sys-apps/dbus-1.6.4 (/usr/lib/systemd/system/dbus.service)
sys-auth/consolekit-0.4.5_p20120320
(/usr/lib/systemd/system/console-kit-log-system-start.service)
sys-auth/consolekit-0.4.5_p20120320
(/usr/lib/systemd/system/console-kit-daemon.service)
sys-auth/consolekit-0.4.5_p20120320
(/usr/lib/systemd/system/console-kit-log-system-restart.service)
sys-auth/consolekit-0.4.5_p20120320
(/usr/lib/systemd/system/console-kit-log-system-stop.service)
sys-auth/polkit-0.107 (/usr/lib/systemd/system/polkit.service)
sys-fs/udev-187-r1 (/usr/lib/systemd/system/systemd-udev-trigger.service)
sys-fs/udev-187-r1 (/usr/lib/systemd/system/systemd-udev-settle.service)
sys-fs/udev-187-r1 (/usr/lib/systemd/system/systemd-udevd.service)
sys-power/upower-0.9.17-r1 (/usr/lib/systemd/system/upower.service)


Yowza! All the packages that provide systemd unit files are installing
them?! But I don't even use systemd. I don't want this cruft on my
system.

Proposal: global USE flag for systemd, just like there's one for openrc.


Thanks,
Jason



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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
optionally install unwanted bloat, we make them an option via a USE
flag. In this case, especially, since systemd isn't even the default
(nor officially supported, whatever that amounts to), users certainly
should not have to manually add an install mask to make portage do
what it already should do.

Besides, as systemd gains momentum, we can probably expect that
various pieces of software will have options to enable a systemd mode
or a systemd build, or what have you, and then in this case, a global
USE flag becomes even more imperative.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 should
actually be /usr/lib/systemd/system.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 differentiation,
maintainers are kind of just stepping on each others toes. There's
simply no protocol for dealing with the increasingly aggressive
upstream systemdification. With a global USE flags, maintainers can
then think about things in terms of okay, the systemd world likes it
this way; the rest of the world likes it this way... therefore: use
systemd  kitten_killer.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 to deal with these
options. On a default install, which uses OpenRC, users shouldn't have
to then emerge an additional program to add more configuration in
order to have a clean system.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 has bash. Not everyone has systemd.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 doesn't hold.

zx2c4@Dell /usr/lib/systemd $ equery d bash|grep portage
sys-apps/portage-2.2.0_alpha120



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 artifacts all over my
 system even when I explicitly ask for it to not be near it.
 Very rude. Very not Gentoo.

+100



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

2012-08-08 Thread Jason A. Donenfeld
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 so far).  Ubuntu is doing similar things with
 Unity/Upstart.

It's worth noting that KDE is actually becoming more independent, as
KDE Frameworks 5 is going to focus on having smaller separate reusable
components, with fewer monolithic dependencies.



Re: [gentoo-dev] Global Systemd USE Flag

2012-08-08 Thread Jason A. Donenfeld
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 pushing
systemd very hard, and its technical merits have gained a lot of sway
in many places. As such, it seems like lots of everything are joining
a fast-paced systemd stampede. Seeing that udevd has been renamed to
something with systemd in the name raises a gut fear oh no, now
something as fundamental as udev is becoming systemdified. It's just a
matter of time before init.d disappears forever. To the
non-systemd'ers, I think the general perception is that without any
set of policies to manage the stampede, systemd will eventually take
over.

Maybe this fear is warranted. Maybe it's silly. I don't know. I am
glad, though, that Gentoo is sticking with OpenRC, and I hope that the
consequences of that decision are respected by ebuild maintainers.



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

2012-07-18 Thread Jason A. Donenfeld
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

2012-07-18 Thread Jason A. Donenfeld
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.


Interesting. Can you talk more about the benefits of mdev in
non-embedded systems? Why would I want to use this instead of udev
(aside from the /usr dispute).



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

2012-01-27 Thread Jason A. Donenfeld
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?

2012-01-27 Thread Jason A. Donenfeld
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 much more important.


I'm *not* suggesting PIE is enabled by default for all packages. This is a
big job with performance losses, etc. I *am* suggesting that PIE is enabled
for all SUID binaries.


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

2012-01-27 Thread Jason A. Donenfeld
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 general instruction be?


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

2012-01-27 Thread Jason A. Donenfeld
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?

2012-01-27 Thread Jason A. Donenfeld
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 have PIE for SUID executable. See the subject of
this thread.


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

2012-01-27 Thread Jason A. Donenfeld
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 their requirements
 (they tend to not be performance sensitive in the slightest), i don't have
 a
 problem with steering them in the PIE direction.


Great!



 ignoring /usr/bin/Xorg here of course, but that has a lot more problems
 that i
 doubt PIE will make much of a difference.


Oh boy. Yea. Oh boy. Xorg should be PIE too, I suppose. Only takes
one rotten egg.



 -mike



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

2012-01-26 Thread Jason A. Donenfeld
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 of
 set*id.


For starters, though, what about just pooping a QA warning for non-PIE
SUID? That way those packages could be fixed, and we'd have a little trial
to see how PIE behaves across different platforms. If that all goes well,
we bump up to default, but that's a far off discussion.



 -mike



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

2012-01-23 Thread Jason A. Donenfeld
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 compile *
all* SUID binaries with PIE, to prevent against any types of future attacks
of this variety?

Jason


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

2012-01-23 Thread Jason A. Donenfeld
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 or when PIE is not
used, the base address is predictable, so it's easy to find where to write
into.


 Here's the trick: it's hard to decide what to compile PIE and what not
 because we generally don't split the build for the two. I guess a good
 point here could be made to build _everything_ PIE, but it can be tricky
 (at least hotot seem not to work on a PIE system).


Doesn't portage already have a check on SUID executables where it checks to
see if they meet a certain standard and also strips them of read
capabilities? Couldn't we just add a QA blurb to this, so that if any SUID
executables are merged that aren't PIE, there's a nice yellow warning? And
then gradually package maintainers would add the required patches?



It would be also a good idea to resume working on the file-based
 capabilities, dropping suid altogether.


Of course. But, different discussion.


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

2012-01-23 Thread Jason A. Donenfeld
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
 this, there has to be someone who goes to look at all the packages and
 corrects them.


Right. It's a big ordeal. I'm *not* suggesting, however, that we
automatically inject a CFLAG or something awful like that.

What I propose is just to *detect* at merge-time whether or not there are
SUID binaries that are not PIE, and if so, spit out a QA warning.

That way, package maintainers could fix things up bit by bit, without
having to burden you alone with tinderbox troubles.


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

2012-01-23 Thread Jason A. Donenfeld
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 things up bit by bit, without
 having
 to burden you alone with tinderbox troubles.

 How do I go about testing with PIE/ASLR on my own box? Is it just some
 CFLAGS?

 A link to some documentation would or just a quick set of instructions
 would be great.





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

2012-01-23 Thread Jason A. Donenfeld
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 xattr still raises the same point this thread is focused
on: if they're not PIE, they can be easily injected, and their xattrs
utilized for nefarious means.


 --
 Thanks,
 Zac