Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Hanno Böck
On Mon, 8 Feb 2021 10:22:21 +
Peter Stuge  wrote:

> "It does mean, however, that GTK 2 has reached the end of its life. 
> We will do one final 2.x release in the coming days, and we encourage
> everybody to port their GTK 2 applications to GTK 3 or 4."

I read that as there will be one more gtk2 release and none after that.

This seems to imply:
* When there's a security flaw in gtk2 there won't be a fix from
  upstream.
* When there's an incompatibility with new infrastructure (e.g. new gcc
  version / new glibc / changing API of libraries gtk depends on) there
  will be no updates from upstream.

This means in all those instances maintainers will have to get patches
from somewhere. We'll likely end up with some form of
gtk-2.x-r[largenumber] with a large patchset at some point.
Maintaining that will be an increasing burden.

No urgency, but a sign to slowly move off gtk2.

-- 
Hanno Böck
https://hboeck.de/



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Hanno Böck
The bindist flags in openssl + openssh were for elliptic curve support,
as people were concerned about patents.
I'm almost certain this affects libressl just the same way, probably
just noone ever bothered to care.

The bindist flags should probably be reviewed and likely removed.
According to Wikipedia [1] the last possibly relevant ECC patent is
valid until 2020. So 2 more days. There shouldn't be any patent
concerns about ECC any more.


[1] https://en.wikipedia.org/wiki/ECC_patents

-- 
Hanno Böck
https://hboeck.de/


pgpa_2EgH5hwV.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread Hanno Böck
If it has any weight:
I think I was the first person to build Gentoo with LibreSSL. I support
this.

I believe pretty much everything that LibreSSL originally was
(consistent codingstyle, cleanup of obsolete/dead code etc.) has
happened in OpenSSL these days. It's more that there's some myth around
LibreSSL from these early days (where the people behind it raised
back then valid criticism about OpenSSL) than any real value.

-- 
Hanno Böck
https://hboeck.de/



[gentoo-dev] Packages up for grabs: aqbanking and friends (German HBCI onlinebanking)

2020-09-04 Thread Hanno Böck
Hi,

I'm listed as the maintainer of aqbanking and a bunch of packages that
are basically just its dependencies (though libchipcard and ktoblzcheck
may be used separately for some functionality).
This is a library for accessing german online banking systems (which
goes under the names HBCI or FinTS) and can be used e.g. with gnucash.

I'm practically not using these any more as I've completely switched to
using the web interface of my bank. I also haven't been very active in
maintaining them and probably should've removed myself a while ago as
the maintainer.

If you care about these please add yourself as a maintainer. I will
remove myself in a few days and assign them to maintainer-needed
status if noone steps up.

The packages include:
net-libs/aqbanking
app-misc/ktoblzcheck
sys-libs/gwenhywfar
sys-libs/libchipcard
sys-libs/libhx

-- 
Hanno Böck
https://hboeck.de/



Re: [gentoo-dev] [PATCH] rebar.eclass: Run tests with new code

2020-05-02 Thread Hanno Böck
On Sat, 02 May 2020 19:31:10 +0200
David Seifert  wrote:

> Please use proper bash brackets and shorten everything to
> 
> [[ ${1} == eunit ]] && local -x ERL_LIBS="."

Looks good, will do.

-- 
Hanno Böck
https://hboeck.de/



[gentoo-dev] [PATCH] rebar.eclass: Run tests with new code

2020-05-02 Thread Hanno Böck
Due to an update of dev-erlang/fast_tls I noticed an issue in the rebar
eclass with tests.

It seems the way the eclass currently works it is running tests with
the library installed in the system, not the code just compiled.

This is obviously not what we want and it also obviously can fail if
the new tests use features that aren't present in the old version in
the system.

The patch below fixes this and runs tests with libs from the current
directory.

Closes: https://bugs.gentoo.org/720448
Signed-off-by: Hanno Böck 
---

diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index 92dd16b08..f9849f0ff 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -105,6 +105,9 @@ erebar() {
(( $# > 0 )) || die "erebar: at least one target is required"
 
local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+   if [ "$1" = "eunit" ]; then
+   local -x ERL_LIBS="."
+   fi
rebar -v skip_deps=true "$@" || die -n "rebar $@ failed"
 }
 


-- 
Hanno Böck
https://hboeck.de/



[gentoo-dev] [PATCH] rebar.eclass: Use := dependency

2020-04-25 Thread Hanno Böck
All erlang rebar based packages should be rebuilt after a subslot
update of dev-lang/erlang.

Right now this is done in some ebuilds, but inconsistent.
Given this affects all packages this should be reflected in the
rebar.eclass, see also [1].

[1] https://bugs.gentoo.org/714702

Closes: https://bugs.gentoo.org/714702
Signed-off-by: Hanno Böck 
---

diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index f2a620fd8..92dd16b08 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -32,7 +32,7 @@ esac
 
 EXPORT_FUNCTIONS src_prepare src_compile src_test src_install
 
-RDEPEND="dev-lang/erlang"
+RDEPEND="dev-lang/erlang:="
 DEPEND="${RDEPEND}
dev-util/rebar
>=sys-apps/gawk-4.1"

-- 
Hanno Böck
https://hboeck.de/



[gentoo-dev] State of the lxde Project

2020-03-19 Thread Hanno Böck
Hello,

I've been the only member of the lxde project for a while.

I recently stopped using lxde myself.

Currently lxde still works, the bug count is relatively low, but it's a
challenging situation. Upstream development has largely stopped and
people have moved to lxqt.

My personal issue why I stopped using lxde was that the latest version
of electron - and subsequently signal - switched its tray icon
implementation to a new API called StatusNotifier which is not
supported by lxde's panel.

There's also one issue where an lxde package depends on a deprecated
version of a library [1]. I assume such issues will become more over
time and it's unclear if there will be any upstream activity fixing
such issues.

If anyone is willing to take over I'm happy to give any guidance I can.
Likely within the next days I'll remove myself from the lxde project,
making it empty.

With approval from the lxqt project I have moved the openbox window
manager, which is shared by lxde and lxqt, to the lxqt project.


[1] https://bugs.gentoo.org/708188
-- 
Hanno Böck
https://hboeck.de/



Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-01-30 Thread Hanno Böck
I'm a bit worried if we should really go down that path.

Not because I have issues with GPL2+ (I'm usually happy with
everything that makes licensing more flexible), but because I'm worried
we're creating a legal minefield.

Think about this: You may ask me if you can relicense all the ebuilds
I've ever written as GPL2+. I'll say yes. Though ask me if you can
relicense all the ebuilds I've ever committed? Well... They came from
bug reports, overlays, heavily edited by other people, and I have no way
of tracking that. I added them under the implicit assumption that
someone who has submitted such an ebuild to bugzilla or to an overlay
with the gentoo/gpl2 copyright line in it would implicitly agree that
they would be redistributed under those conditions. IANAL, but I think
that's a fair assumption. But do all these people that created or
contributed to the ebuilds I ever committed agree to a
GPL2+-relicensing? No idea, probably not. Is their work relevant enough
to have a license at all? IANAL.

*If* Gentoo decides to go this relicensing way I'd recommend to only do
that if it's coordinated with organizations that have deep legal
knowledge of these issues (e.g. like software freedom conservancy) and
if some lawyers that know this stuff well approve the plan.

-- 
Hanno Böck
https://hboeck.de/


pgpoBtmFxekQw.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-07 Thread Hanno Böck
On Sat, 04 Jan 2020 19:41:21 +0100
Michał Górny  wrote:

> On Sat, 2020-01-04 at 08:38 +0100, Hanno Böck wrote:
> > On Fri, 3 Jan 2020 15:48:54 +0100
> > Toralf Förster  wrote:
> >   
> > > #   Restrict potential illegal access via links
> > > # 
> > > fs.protected_hardlinks = 1
> > > fs.protected_symlinks = 1   
> > 
> > Given the issues with openrc:
> > Wouldn't it be a good idea to add these by default to Gentoo's
> > sysctl.conf in baselayout?  
> 
> Yes, we should.  This really sounds like some horror where developers
> are hacking things around in sources instead of communicating with
> people maintaining the component where a proper fix belongs.

I created a bug for this so we can move the discussion there:
https://bugs.gentoo.org/704914

Particularly if anyone thinks this is a bad idea or knows of a
situation where this breaks things please speak up now in the bugreport.

-- 
Hanno Böck
https://hboeck.de/


pgpu2QXCFT33y.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Hanno Böck
On Fri, 3 Jan 2020 15:48:54 +0100
Toralf Förster  wrote:

> #   Restrict potential illegal access via links
> # 
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1 

Given the issues with openrc:
Wouldn't it be a good idea to add these by default to Gentoo's
sysctl.conf in baselayout?

As far as I understand this from the thread by now, these are set by
default by Gentoo Sources. So we shouldn't really expect much breakage
if we set them via sysctl.


-- 
Hanno Böck
https://hboeck.de/


pgp0gbqf5JHKL.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs: app-arch/unar

2019-12-10 Thread Hanno Böck
On Mon, 09 Dec 2019 19:56:40 +0100
Dennis Schridde  wrote:

> app-arch/unar currently seems to be the only free choice for kde-apps/
> kdeutils-meta-19.08.3[rar]:
> rar? ( || (
> app-arch/rar
> app-arch/unrar
> app-arch/unar
> ) )

I believe this is obsolete, I can unpack rar with ark and plain
libarchive.

I opened a bug for this, further discussion should go there:
https://bugs.gentoo.org/702426

-- 
Hanno Böck
https://hboeck.de/


pgpbr0bbWbkcD.pgp
Description: OpenPGP digital signature


[gentoo-dev] Package up for grabs: app-arch/unar

2019-12-09 Thread Hanno Böck
Hi,

I'm no longer interested in maintaining app-arch/unar.

It's an archive unpacker written in objective C, which makes it
dependency-heavy (particularly requires gcc compiled with objc).
I originally got interested because it was the only free unpacker
capable of handling modern rar archives. However libarchive does that
these days, so I don't see a strong need for unar any more.

There's a bump request, but upstream changed the code structure and
separated out a library, so it's not completely straightforward:
https://bugs.gentoo.org/702024

If you're interested please add yourself to metadata.xml and remove me,
if noone picks it up I'll make it maintainer-needed in a few days.

-- 
Hanno Böck
https://hboeck.de/



Re: [gentoo-dev] RFC: Create ejabberd project

2019-10-29 Thread Hanno Böck
On Mon, 28 Oct 2019 18:46:15 +0100
"Haelwenn (lanodan) Monnier"  wrote:

> > https://wiki.gentoo.org/wiki/Project:Ejabberd  
> 
> Wouldn't a Erlang project be better, specially as there is the Perl
> and Python projects which are there for probably the same reasons?

An erlang project would create a wrong impression. I have currently no
interest in maintaining the larger erlang ecosystem.
If there is developer interest in a generic erlang project that would
of course be fine, but it would be a project with a different focus.
(And I don't think there would be any problem coordinating the 2
projects if they exist, but for now that's a hypothetical situation.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



[gentoo-dev] RFC: Create ejabberd project

2019-10-28 Thread Hanno Böck
Hi,

I'm currently working on getting ejabberd up to date in Gentoo.

There are a bunch of dev-erlang/* packages whose primary reason for
packagin is that they're dependencies of ejabberd (and they're becoming
more), most of them currently in maintainer-needed status.

I'd like to group those together as maintained by an ejabberd project
and a corresponding mail alias. (And hopefully in the long term won't be
the only person being in that Project.)

https://wiki.gentoo.org/wiki/Project:Ejabberd

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] [PATCH] glep-0075: Update for reference implementation

2019-10-24 Thread Hanno Böck
On Thu, 24 Oct 2019 22:39:06 +0200
Ulrich Mueller  wrote:

> In the rationale section, one reason given for the choice of the hash
> algorithm (BLAKE2B) was to "avoid code duplication". Isn't that
> argument moot, if all hashes supported by Portage are implemented?
> (Or in other words, couldn't a faster hash function like MD5 be used?)

FWIW blake2b is faster than md5. That was one of the design goals [1].


[1] https://blake2.net/

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpOM0rnOKMot.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: app-office/geierlein

2019-09-23 Thread Hanno Böck
# Hanno Boeck  (2019-09-23)
# Depends on an API by German tax authorities that
# has been disabled, bug #695434
app-office/geierlein


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



[gentoo-dev] Package up for grabs: app-shells/mksh

2019-01-13 Thread Hanno Böck
Hi,

mksh is a shell coming from mirbsd/miros.

I haven't touched the package for a while, but I was still listed as
the maintainer. The upstream author is usually responsive.

There are a few open bugs, mostly issues with tests. Right now I can't
even get it to compile with FEATURES="test" (it hangs at one test
forever).

Feel free to take it if you're interested. I have assigned the bugs to
maintainer-needed and removed myself from the metadata.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



[gentoo-dev] Packages up for grabs: openvas

2018-12-12 Thread Hanno Böck
Hi,

I practically haven't maintained openvas for quite a long time, yet
unfortunately am still listed as the maintainer. It's a security scanner
and a fork of nessus.
It needs version bumps, updated ebuilds are in bugzilla, but I don't
know if they're for the very latest version [1].

In my experience upstream changes things often and makes the usability
more complex with every new release while providing little value (I
mostly got false positives out of it in the past).

The following packages belong to it:
net-analyzer/openvas
net-analyzer/openvas-manager
net-analyzer/openvas-cli
net-analyzer/openvas-tools
net-analyzer/openvas-libraries
net-analyzer/openvas-scanner
net-analyzer/greenbone-security-assistant
net-analyzer/ospd

Feel free to take it and remove me, otherwise I'll remove myself soon
and make it "maintainer-needed".

[1] https://bugs.gentoo.org/590324

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] [RFC] Removing barely used global flags

2018-10-23 Thread Hanno Böck
On Sat, 20 Oct 2018 12:41:03 +0200
Michał Górny  wrote:

> We seem to have a lot of global flags that are used only by a few
> packages.  How about moving them to local flags?  List of flags with
> less than 5 packages using them, ordered by use count, follows.  Where
> applicable, local flag descriptions are listed.

No disagreement in principle, however it might be worth checking which
of them are practically used at all or could be removed entirely.

"directfb" caught my attention, which I doubt is very active today.
Though the package in question - libggi - only uses the directfb flag
in an old ebuild, the latest one hard-disables directfb.
So well, if you stabilize libggi-2.2.2-r1 and remove the old ebuild you
can entirely get rid of this useflag instead of making it local.

Plausibly there may be other such cases, i.e. flags that were used in
the past, but for things that got deprecated / out of fashion / are
practically no longer used.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpD2YYux9maw.pgp
Description: OpenPGP digital signature


Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

2018-08-04 Thread Hanno Böck
Hi,

On Sat, 4 Aug 2018 11:43:28 +0300
Andrew Savchenko  wrote:

> Do you have any evidence that mcrypt should not be used?

Well, PHP was as far as I'm aware its main user and PHP has declared
mcrypt support to be deprecated a while ago.

> Symmetric cryptography is quite conservative and it took years and
> even decades for algorithms and their implementations to become
> trusted, so there is nothing wrong in using good old verified
> software.

When it comes to cipher modes the fact that people use decades old
modes is a problem. See efail for a prominent example, but there
are many less prominent ones.

Look at the mcrypt webpage:
http://mcrypt.sourceforge.net/

Modes of Operation:

CBC
CFB
CTR
ECB
OFB
NCFB

That is a mixture of very insecure (ECB), insecure in most situations
(all others) and totally obscure modes. It doesn't include any
authenticated encryption modes, which in most situations is what you
want to use.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpVU0M0tWo7W.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Trustless Infrastructure

2018-07-02 Thread Hanno Böck
Hi,

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.

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.
And I believe these challenges are one of the reasons the old attempts
to have a signed Gentoo never went anywhere. I'm glad we have some form
of signed Gentoo now, even if it relies on some centralized
infrastructure.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Idea for a new project: gentoo-libs

2018-06-25 Thread Hanno Böck
On Fri, 22 Jun 2018 21:50:50 -0500
"Marty E. Plummer"  wrote:

> So, as you may be aware I've been doing some work on moving bzip2 to
> an autotools based build. Recently I've ran into app-crypt/mhash,
> which is in a semi-abandoned state (talking with the maintainer on
> twitter atm), and I was thinking it may be a good idea to set up a
> project for keeping these semi-abandoned and really-abandoned
> libraries and projects up to date and such.

This is a common problem, however if you want to make this reasonable
you wouldn't make it a gentoo thing, but a cross-distro effort. The
idea has been tossed around a lot, but noone yet started implementing
it.

However keeping things alive may not always be the right option.
There's a reason mcrypt is abandoned. It's an ancient crypto library,
crypto is moving forward, there are better options. THe main user of
mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other
users in the gentoo tree of libmcrypt, which are both rather obscure
packages - nsca and elettra.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Regarding the State of PaX in the tree

2018-04-16 Thread Hanno Böck
Hi,

I honestly don't see how it would be feasible to maintain a feature
that the developers maintaining it have access to.

I get that this whole pax-thing embodies a huge part of Gentoo history
and it may feel hard for some to let it go. But things are how they are.

Regarding the fork states: I followed up on minipli's fork, which
tried to maintain newer patches of grsec for LTS kernels, but that
essentially stopped after KPTI/meltdown/retpoline. From what I know
there's no public grsec patch with kpti or any spectre fixes, thus I
would very much say you're safer these days with an upstream kernel.

I think the only realistic way this support can be upheld would be if
some people who have access to the grsec sources commit to making sure
that it is maintained.


There's also another question related to this: What's the future for
Gentoo hardened?
From what I can tell hardened consists of:
* the things that try to make it compatible with grsec/pax
  (more or less obsolete).
* things that are now in default profiles anyway (aslr, stack
  protector).
* things that probably should be in default profiles (relro, now linker
  flags)
* -fstack-check, which should eventually be replaced with
  -fstack-clash-protection (only available in future gcc's) and that
  should probably also go into default profiles.
* Furthermore hardened disables some useful features due to their
  incompatibility with pax (e.g. sanitizers).

So it's stuff that either is obsolete or probably should be a candidate
for main profiles. Maybe we should strive for "hardened-by-default".

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

2017-10-27 Thread Hanno Böck
Hi,

On Thu, 26 Oct 2017 22:12:25 +0200
Michał Górny <mgo...@gentoo.org> wrote:

> After a week of hard work, I'd like to request your comments
> on the draft of GLEP 74. This GLEP aims to replace the old
> tree-signing GLEPs 58 and 60 with a superior implementation and more
> complete specification.

Thanks for working on this, it's really one of the biggest security
issues Gentoo has these days that need to be fixed.

I hope I'll find time to read it in detail, but by skimming through it
I noted that the downgrade attack prevention is kinda not very clear.
It says in the timestamp section "The package manager can use it  to
detect an outdated repository checkout." But it doesn't say how exactly.

Should a package manager reject a sync if it is too old? or not install
packages if a sync hasn't happened for some time? What is considered
"outdated"? I think that should be clarified how exactly it's supposed
to work.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Manifest2 hashes, take n+1-th: one hash to decide them all

2017-10-25 Thread Hanno Böck
Hi,

On Wed, 25 Oct 2017 02:40:58 +
"Robin H. Johnson" <robb...@gentoo.org> wrote:

> At that point, and this is a serious proposal:
> The package manager shall decide which hashes to check, but is
> required to check at least one hash. The choice may be 'fastest',
> 'most secure', or any local factor.

Sorry to contribute again to the bikeshedding, but I'd really like to
get one thought across here:
Good security includes reducing complexity. Tough (as evident by this
thread) it's a thought many people find hard to accept.

I don't think this is most important in this discussion, but I feel
it's something people should keep in mind also for other decisions to
be made.

This thread is going into a completely different direction and I find
that worriesome. We have two non-problems ("what if secure hash X gets
broken?" and "what if it's too slow? I haven't benchmarked, but what if
it's too slow??") and people proposing increasingly complex solutions.

If you do what you propose my worries aren't that any hash gets broken
or that it's too slow. It's that some bug will chime in where in some
situation no hash gets checked whatsoever.

Having more than one hash is already unneeded complexity. Nobody does
that. TLS signatures use one hash. GPG signatures uses one hash. Signal
uses one hash. I'm not aware of any credible cryptographic product that
feels the need to have multiple hashes concatenated. (The only real
example I'm aware of is old TLS versions who chose to concat two
insecure hashes - MD5+sha1 - which obviously wasn't the smartest idea
either, but one can credibly say they didn't know better back then.)

Having a situation where one can either check one hash or multiple and
add configurability around that is another step of adding unneeded
complexity.


Also one more comment about the issue with potentially buggy Hash
implementations: I feel this is a software testing problem rather than
anything that should influence our package manager format or be tested
at runtime. Add a self-test of hash functions with a large batch of
test vectors that you can easily run.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpNTzKQZ2nN3.pgp
Description: OpenPGP digital signature


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

2017-10-21 Thread Hanno Böck
On Sat, 21 Oct 2017 12:12:44 -0500
R0b0t1 <r03...@gmail.com> wrote:

> That is precisely why I didn't suggest it be used on its own (see note
> about extant use of MD5), and why I gave alternatives. If it is
> desired that the hashes be computed quickly then weaker hashes will
> need to be used. One usually can't have both security and speed.

You can have that. Blake2 is faster than any broken legacy hash.
And ripemd isn't particularly fast

> People are discussing collision resistance, but no one here appears to
> be trained in cryptography.

For the record, I'd claim I am.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



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

2017-10-20 Thread Hanno Böck
On Fri, 20 Oct 2017 11:23:06 +0200
Ulrich Mueller <u...@gentoo.org> wrote:

> >>>>> On Fri, 20 Oct 2017, Dirkjan Ochtman wrote:  
> 
> > As Hanno was saying, we'll have decades of warning before a break
> > becomes practical, so I don't think this is a real concern.  
> 
> How can we be sure of that? I guess the same reasoning was applied
> when MD5 and SHA1 hashes were used.

MD5 warning 1996:
ftp://ftp.iks-jena.de/mitarb/lutz/crypt/hash/dobbertin.ps

MD5 broken 2005:
http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf

SHA1 warning 2005:
https://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf

SHA1 broken 2017:
https://shattered.io/


It's reasonable to assume that modern hash functions will have a far
longer warning period. For two reasons:
* their safety margin is much higher to begin with, particularly if
  you choose something like SHA512 (256 bit collission resistance). It
  was more or less always clear that MD5 (64 bit) and SHA1 (80 bit) are
  in risky terrain even without any cryptographic breakthrough.
* hash function research in 2017 is lightyears ahead of hash function
  research in the 90s and early 2000s. One major outcome of the
  research after the big hash breakdown in 2005 was that SHA-2 is much
  safer than people previously thought.


I don' have a very strong opinion on this. Having two hash functions
probably won't harm. Though I tend to prefer the simplest solutions if
it's secure. And all my cryptographic knowledge tells me that "What if
sha512 is broken?" isn't a realistic problem to be concerned about.


I do feel it's a bit ironic that we have these lengthy discussions
about hash functions while at the same time they provide little
security to begin with, because they aren't transmitted over a secure
channel and not signed...

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpR5FdZLlUJa.pgp
Description: OpenPGP digital signature


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

2017-10-19 Thread Hanno Böck
On Thu, 19 Oct 2017 21:08:40 +0200
Michał Górny <mgo...@gentoo.org> wrote:

>   manifest-hashes = SHA512 SHA3_512

Counterproposal: Just use SHA512.

There isn't any evidence that any SHA2-based hash algorithm is going to
be broken any time soon. If that changes there will very likely be
decades of warning before a break becomes practical.

Having just one hash is simpler and using a well supported one like
SHA512 may make things easier than using something that's still not
very widely supported.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Packages up for grabs net-im/pyaim-t

2017-10-10 Thread Hanno Böck
On Mon, 9 Oct 2017 16:03:35 -0400
Brian Evans <grkni...@gentoo.org> wrote:

> AOL Instant Messenger will be retired on Dec 15, 2017.  Last rite this
> and any other package that is the sole consumer of that service.

Proposal:
Let it in the tree without a maintainer until that date (Dec 15) in case
anyone still wants to use it to say their aim friends goodbye, then
lastrite it.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpehf5s181s7.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] sys-boot/grub:0 (GRUB legacy) sunset planning

2017-09-03 Thread Hanno Böck
Hi,

On Sat, 2 Sep 2017 15:56:04 +
"Robin H. Johnson" <robb...@gentoo.org> wrote:

> - Are there other use cases that need grub-static?

I have used grub-static to boot Gentoo Systems built with Address
Sanitizer.

I have to check whether it's feasible to replace that with grub2, but
it will probably be complicated. The problem is that you can't build
full grub with asan, but you also cannot build the parts that require
external libraries (notably ncurses) without asan.

If grub-static gets last-rited from main gentoo I'll probably just keep
a copy of it in the asantoo overlay.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpYskrxPOZvj.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols

2017-08-25 Thread Hanno Böck
On Wed, 23 Aug 2017 11:46:02 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:

> Sigh... https also makes MITM attacks possible, especially if SSL
> or TLS < 1.2 is used or are allowed and protocol version downgrade
> attack may be performed.

None of that is true.

You're probably referring to attacks that were specific to certain
browser weaknesses, but they're irrelevant for this use case.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpw64X7an5Wn.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: app-arch/unrar-gpl

2017-08-21 Thread Hanno Böck
# Hanno Boeck  (21 Aug 2017)
# Open security bugs, no upstream, bug 628432
# Alternatives: app-arch/libarchive, app-arch/unar
app-arch/unrar-gpl



Re: New profiles for default-pie transition (was: Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2)

2017-05-10 Thread Hanno Böck
On Wed, 10 May 2017 15:29:19 +0200
"Andreas K. Huettel" <dilfri...@gentoo.org> wrote:

> * generate a new set of profiles 17.0 where it's package.use.forced
> * tell people they may have to rebuild world when they switch

Do we really need to rebuild world?
From what I understand problems arise if we have packages installing
static libraries that aren't built position independent.
However that's only a small fraction of packages and we should be
easily able to detect them.

Can't we just provide a small script or bash oneliner that will rebuild
all affected packages?

(other than that I think the profile plan sounds reasonable)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

2017-05-10 Thread Hanno Böck
Hi,

On Wed, 10 May 2017 07:28:15 + (UTC)
Martin Vaeth <mar...@mvath.de> wrote:

> I am using gcc-6 since ages and tried to run a desktop with default
> pie for quite a while, but soon was forced to give up:
> 
> There are simply too many package which fail to compile;
> this cannot even be recommended to early testers yet, not to speak
> about the wide public.

I could add my voice that I ran pie by default for a while and haven't
seen any pie-specific issues, but that doesn't get us anywhere.

We have a tracker bug for default-pie-problems in bugzilla:
https://bugs.gentoo.org/show_bug.cgi?id=582688

*All* bugs that block this bug are currently marked as resolved. So if
you are aware of any open issues that need to be taken care of please
file a bug and make sure they block the tracker bug.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

2017-05-09 Thread Hanno Böck
Hi,

On Tue, 09 May 2017 15:55:36 -0500
Matthias Maier <tam...@gentoo.org> wrote:

> Well, Alexis certainly makes a strong point. Breaking installed static
> archives by changing a use flag shouldn't be as easy as changing a
> useflag. So we might simply use.force the pie use flag depending on
> hardened/non-hardened profiles.

While I understand that enabling pie requires some more planning to
avoid breakage, I hope this is not the final solution we aim for. I
really think it's about time that pie becomes the default in Gentoo.

pie is required for working ASLR, which almost every other OS out there
has these days. In recent years also Fedora, Ubuntu and lately Debian
switched it on by default. I really think this should be a default
security setting, not something that only lives in hardened.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] gcc-6.x status inquiry

2017-05-03 Thread Hanno Böck
On Wed, 3 May 2017 11:43:11 -0500
William Hubbs <willi...@gentoo.org> wrote:

> I see that gcc-6.3 doesn't have keywords, so I'm
> wondering when it will get them? Does anyone have any idea? I'm not
> talking about stable keywords, just ~. ;-)

Given that gcc 7.1 was just released and gcc 6 isn't even keyworded yet
I'm wondering if it'd be an idea to right away strive for gcc 7 and
skip keywording+stabilizing gcc 6.x in gentoo.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgptZTut91Vj6.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

2017-04-03 Thread Hanno Böck
Hi,

On Mon, 3 Apr 2017 22:00:15 +0200
Dirkjan Ochtman <d...@gentoo.org> wrote:

> First of all, SHA-256 should be safe for all intents and purposes, and
> for the foreseeable future. This is nothing like Git's usage of SHA-1,
> which was known to be on the way to brokenville for a long time. I
> don't think there is a solid reason for deprecating it now.
> 
> Second, the amount of diversity proposed does not make sense. If
> asked, I would propose we keep SHA-256 as one of the options and
> additionally add a SHA3 variant and a BLAKE2 variant as other options.
> This would provide more than enough diversity. Also totally agreed
> with Vadim on the obscurity of the GOST algorithms.
> 
> But, this is the kind of thing where we really should get input from
> the Security project, so we should get people like Hanno and Kristian
> involved.

As you specifically asked for my opinion:
I think there's no reason to doubt the security of any of the sha2
hashes (including sha256), any of sha3 or blake2 for the forseeable
future. (That means counting in many decades - there isn't even a shred
of evidence sha256 is going to be broken any time soon.)
There's no point in deprecating anything.

I find it unnecessary to introduce additional complexity here and
adding obscurity algorithms like gost sounds really bizarre and
unnecessary. I'd recommend against introducing anything that
requires unusual dependencies.
If anything I'd propose to just change to a single hash functio

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



[gentoo-dev] Packages up for grabs from sci-geosciences category

2016-09-28 Thread Hanno Böck
Hi,

Continuing my efforts not to be listed as a maintainer for packages I
don't really care about: There are a bunch of packages in the
sci-geosciences category that I maintained a long time ago when I was
active in the openstreetmap community.
All of them are listed with the sci-geosciences project as a maintainer
as well, so I'll just remove myself and leave the project
maintainership in a few days. But if anyone wants to jump in feel free
to take the packages (just remove me and add yourself in that case).

sci-geosciences/gebabbel
Frontend for the tool gpsbabel. Strangely enough we have 0.4, while
upstream seems only to have 0.3. There are no open bugs, so it seems a
relatively stress free package and it can probably just stay the way it
is.

sci-geosciences/gpscorrelate
Tool to add gps coordinates based on gpx tracks. No open bugs, latest
version, so it seems stress free and can probably stay without a
dedicated maintainer.

sci-geosciences/josm
The Java OpenStreetMap editor. It was the standard way of editing
openstreetmap in the past, but since the web editor got much betters
I think it's relevance is smaller these days. nixphoeni has done the
last version bumps, I already asked him directly if he wants to take
over maintainership.

sci-geosciences/mkgmap
Tool to create garmin maps from openstreetmap data. I don't have any
garmin device any more.
This is many years behind upstream and whoever wants to take it will
probably have to face some complicated java-dependency-management
issues, see here:
https://bugs.gentoo.org/show_bug.cgi?id=402943
If nobody wants to take it we may want to last-rite this. Upstream
provides precompiled jar versions, it probably makes more sense that
people use those instead of our heavily outdated ebuild.

sci-geosciences/osm2mp
This is probably deprecated. It turns openstreetmap data into a format
called mp which was used by mkgmap (see previous). Later versions of
mkgmap were directly capable of using osm data, therefore that use case
is gone.
However not sure if there are other uses of mp. Anyway, no open bugs,
so it seems trouble free and may just stay if there is any use of it.

sci-geosciences/osmosis
Command line tool to interact with the osm api. Similar problem as
mkgmap with complex java dependency stuff. Years behind upstream, see:
https://bugs.gentoo.org/show_bug.cgi?id=402945
As with mkgmap I'd recommend last-riting this if no maintainer steps in
to tackle this.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



[gentoo-dev] Package up for grabs: skencil

2016-09-16 Thread Hanno Böck
media-gfx/skencil
is a python-written vector graphics tool. It was once popular before
inkscape became the de-facto-standard. It hasn't seen any upstream
activity for a decade(!), but surprisingly it still seems to work.

I haven't used it for many years myself.

There are 4 open bugs in bugzilla.

Anyone interested in taking it? (else the usual: will be reassigned to
maintainer-needed)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42



Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread Hanno Böck
On Sun, 07 Aug 2016 10:22:28 +0200
Pacho Ramos <pa...@gentoo.org> wrote:

> Now https://wiki.gentoo.org/wiki/Project:LXDE is empty
> 
> Feel free to join, anyway, if I don't misremember, LXDE is dead for a
> long time in favor of LXQT... in that case treecleaning the packages
> would also be an option

Oh...

I'm actually using lxde and I have recently pushed a bunch of memory
safety fixes to upstream that were a result of my address sanitizer
testing.

LXDE upstream isn't totally dead, occasionally releases with fixes
happen, yet they're slow.

I'll look that I maintain some of the stuff, yet I'd prefer if I'd be
not the only one.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Herd likely up for grabs: net-im

2016-01-19 Thread Hanno Böck
On Mon, 18 Jan 2016 19:19:31 +
Amadeusz Żołnowski <aide...@gentoo.org> wrote:

> Michał Górny <mgo...@gentoo.org> writes:
> > Packages currently in herd along with their other maintainers:
> > [...]
> >
> > net-im/ejabberd  :   
> 
> I have not much knowledge about erlang stuff, but I will take ejabberd
> if noone else wants. Co-maintainers are welcome.

I would love if ejabberd gets maintained again :-)

I recently tried to update it, but it's a bit annoying, upstream makes
things really hard. They live-git-checkout various things (and
adapt that based on config flags) and don't provide a tarball including
everything that's needed.
The last person working on that was radhermit.

Maybe we can try to fix that together and get a new version into the
tree.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgp4bfmlg8BUe.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Gentoo Dinner@FOSDEM 2016

2016-01-13 Thread Hanno Böck
On Wed, 13 Jan 2016 09:19:08 +
Xavier Miller <xaviermil...@gentoo.org> wrote:

> So, please contact me here, on the forum, or at #gentoo-fosdem.

I probably won't make it to the dinner, but I'm giving a talk about how
to run Gentoo with Address Sanitizer in the security devroom.

I've added a note to the wiki, hope that's okay.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Hanno Böck
On Mon, 4 Jan 2016 01:26:28 +0100
Sebastian Pipping <sp...@gentoo.org> wrote:

> Better late then never.  Posting 72 hours from now the earliest as
> advised by GLEP 42.  Feedback welcome as usual.

afaics this only affects users using the mod_php variant of PHP and not
any fcgid or fpm solution. I think this should be mentioned.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] RFI: A better workflow for github pull requests

2015-09-12 Thread Hanno Böck
On Sat, 12 Sep 2015 21:12:25 +0200
Michał Górny <mgo...@gentoo.org> wrote:

> 1. Many of the Gentoo developers have different nicknames on GitHub.
> Some developers don't even set their real names which makes them even
> harder to find.

This isn't directly related to your proposal, but may I jump in here:
Wouldn't it be in general valuable to track the connection gentoo dev
handle <-> github handle in a machine readable and generic way?

Should / could we add that as an ldap attribute or something?

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpoomRUUh5oh.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] broken link in gentoo-portage-rsync-mirror readme, changing repo URI

2015-08-16 Thread Hanno Böck
Also saw the wrong URL and sent a pull request to fix that earlier
today:
https://github.com/gentoo/gentoo-portage-rsync-mirror/pull/195



-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



[gentoo-dev] Creating a Gentoo built with Address Sanitizer

2015-07-02 Thread Hanno Böck
Hi,

A quick intro for people who don't know address sanitizer (asan): It's a
feature of gcc and clang adding bounds-checking to c (enabled with
-fsanitize=address command line), which will cause applications to crash
and throw an error if an invalid memory access happens.
Very simple example:
int a[2]={1, 1};
int b=a[2];

This is invalid because a[2] does not exist, but usually software will
silently ignore such errors. Address Sanitizer catches them.

Address Sanitizer is supposed to be a debugging-tool, because it slows
down things quite a lot.

I've been playing with the idea of having a full system with almost
everything build with address sanitizer for quite a while. Gentoo is
obviously a good choice for such a system due to it being source based
and flexible.

I by now have a rudimentary system running in a chroot where everything
except glibc, gcc and some deps of gcc is built with asan. I'll probably
publish a stage tarball at some point. As asan has been around for a
while a lot of stuff is already fixed, so often it's merely a take the
newer version of package X and it works. But in the process of trying
to run such a system I already reported a couple of bugs to the
corresponding upstreams (e.g. recently in bash).


Why's that interesting? First of all it lets you find bugs. There may
be corner cases, but I'm right now not aware of any situation where an
error by address sanitizer happens in legit code. An out of bounds
access or other memory access errors are always a bug.
So in an ideal world it should be possible to just recompile
everything with asan and it runs. (You just need to consider the order
of recompiling things - you can run an asan-ized software with
non-asan-libs, but you cannot do it the other way round: non-asan
software with asan-libs break.)

Such a system could also be interesting as a high security linux
variant not vulnerable to common buffer overflows and other memory
errors. It is slower, but that may be acceptable. (However it should be
said that right now asan is incompatible with grsecurity - and probably
people who want a high secure linux variant want grsecurity.)

For now I just wanted to announce that I'm working on this, so people
who care can get in touch with me. I'll probably write a detailed blog
post at some point.
Depending on how much interest there is this may be something Gentoo
wants to consider as an official project and publish official stage
tarballs.

cu, Hanno
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] libressl status

2015-04-02 Thread Hanno Böck
On Thu, 2 Apr 2015 16:49:20 -0700
Paul B. Henson hen...@acm.org wrote:

 What is the current status/thoughts regarding libressl? Reviewing the
 bug and some past threads, it sounds like the initial plan was to make
 openssl a virtual and let either classic openssl or libressl fulfull
 it? I'm not sure if things have changed from that viewpoint, but it
 really doesn't seem they're going to be plug and play compatible 8-/.
 libressl offers functionality openssl doesn't and vice versa, and
 playing nicely with each other doesn't seem to be on the agenda of
 either.

The latest state is that there is an overlay, but making the portage
tree compatible with libressl is not that trivial.

A large number of core packages are upstream-incompatible with
libressl. Most of them are actually programming languages (python, php,
ruby) that contain bindings to functions libressl has removed.
This could be fixed by the upstreams with some ifdefs, but right now
you can't just switch out libressl.


 It seems it might make more sense to treat them more like
 openssl and gnutls, where they both provide similar ssl functionality
 but a given package might use one, the other, or either?

Tricky thing here, because then you'd need to rename the libs. E.g.
libssl to liblibressl or something.
But then every program with a build environment to link to libssl would
first have to be patched to link to our specialized libressl variant.


 The specific reason for my current inquiry is that the latest openntpd
 release includes the new support from openbsd for constraints, where
 basically you can verify ntp time sources by checking their time
 relative to a trusted TLS server (which provides the time in HTTP
 headers). This functionality requires libtls, part of libressl.
 openssl provides no compatible functionality, so this is a case where
 they're not plug-and-play, openntpd requires libressl specifically.

I'm eager to use that, too, and was disappointed to read it requires
libressl :-)
Is there a way to split libtls off libressl? Because that might be at
least for this case an option: Continue to use openssl, but have libtls
laying around. Not sure if it is possible to have libtls using
libcrypt/libssl functions from openssl.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks

2015-04-01 Thread Hanno Böck
On Wed, 01 Apr 2015 14:59:01 +0200
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:

 As far as I know this is correct.
 All SSL protocol versions including v3 have known vulnerabilities.

Yeah, but this is a pointless statement in the discussion. Nobody says
we should deploy https via sslv3. Of course if people want https they
mean https as in 2015 https, not https as in 199x https.

 In addition, a number implementations of TLS 1.0 and 1.1 have been
 found susceptible to the Poodle and/or FREAK attacks.

Implementation bugs that can be fixed (and are fixed).

FREAK is only an issue if you have crazy configured servers (again,
https as in 199x), POODLE TLS is only affecting some crappy proprietary
load balancers (and erlang, but nobody has proposed to use an erlang
https server).

People want to deploy pgp sigs (which is - to be clear - a good idea I
fully support). I personally found countless minor security issues in
gpg lately. Should that stop us from using pgp sigs? of course not.


And the claims about https being a performance / cpu stress horror is
also completely exaggerated. https performance is mostly a non-issue
and based on urban legends rather than benchmarks.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Should Gentoo do https by default?

2015-03-29 Thread Hanno Böck
On Sun, 29 Mar 2015 16:46:05 +0200
Michał Górny mgo...@gentoo.org wrote:

 While I don't mind this entirely, we need to make sure to get things
 right. For example, I'm quite unhappy being unable to use Forums or
 sources.g.o from my phone because of some SSL issues…

Can you be more specific on that? Of course if there are problems we
should fix them - and I'm glad to help in analyzing those.
(However there are some unfortunate issues that are hard to fix, e.g.
some devices relying on broken protocols like sslv3 - but I think these
should be rare)

What phone? Should we move such issues to bugzilla? (cc me if you open
a bug)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpyyxhG77Xma.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Hanno Böck
On Sun, 29 Mar 2015 23:35:54 +0600
Vadim A. Misbakh-Soloviov m...@mva.name wrote:

 Despite of all you're talking about is right from paranoid point of
 view, I'd, anyway, say DO NOT DO THAT, because you propose to
 revoke the right of choice from the users.

A right of choice from the user only makes sense if there is a
reasonable choice.

Just to take this to the extreme: Should we add a heartbleed-enabled
version of openssl back to the portage tree? It's the choice of the
user if they want to have heartbleed enabled, right?

If there is no disadvantage for the more secure protocols then there is
no need for a choice.

 Moreover, there are some times where it is impossible to fetch
 sources via secure way, but you need it right here and right now.

This has been said before, also in the thread about the webpage. Can
you say what times that would be?
Basically these days it's not possible to use the mainstream internet
without https (you can't search google or log into facebook without
https).
I'd really like to hear of any real world situation where this is an
issue.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpQ0bCBb3afe.pgp
Description: OpenPGP digital signature


[gentoo-dev] Should Gentoo do https by default?

2015-03-27 Thread Hanno Böck
Hi,

Right now a number of Gentoo webpages are by default served over http.
There is a growing trend to push more webpages to default to https,
mostly pushed by google. I think this is a good thing and I think
Gentoo should follow.

Right now we seem to have a mix:
* A number of webpages default to http and have optional https
  (www.gentoo.org)
* Some with sensitive logins are already https by default (e.g.
  bugs.gentoo.org), but they don't use hsts, which they should
* Some with logins are mixed http/login-via-https, which makes them
  vulnerable to ssl-stripping-attacks (e.g. wiki.gentoo.org)

I'd propose the following:
* Make all pages under .gentoo.org https by default
* Make sure all use modern HTTPS features, including:
 * OCSP Stapling
 * HSTS
 * A secure collection of cipher suites
 * (one may add HPKP here, but it requires careful planning and has the
   potential to lock people out of the page if done wrong)
(On the long term I think it would also be good to have downloads over
https, but I'm aware that this is more difficult as it involves mirror
operators that are not under direct control of gentoo infrastructure.)

As I know these discussions, I'll already answer to some
counter-arguments that may come up:

It's not neccessary to do https on pages without logins
These kinds of arguments show a fundamental misunderstanding of what
https does. It guarantees confidentiality *and* integrity. In short, it
protects content not only from observation, but also from manipulation,
which is always a good thing. A very practical example is that on some
networks foreign ads get injected into other peoples webpages.

Makes things slower / servers can't handle it
The performance costs for TLS on a server are often vastly overstatet.
The performance hit on servers doing https is very close to zero, it
just doesn't matter much.
There are some latency problems for connections, but these can mostly
be wiped out by a sane configuration of the server. If http/2 is used
one can even improve the performance with https.

Certificates are too expensive
Gentoo already has certs for all pages, so this is not an argument
here, but if this ever becomes an issue there are a number of CAs these
days that issue free certs. In summer the community based CA Let's
encrypt will start which will be another option.

CAs are bad and the whole system is broken
Partly true, but it doesn't get any better if people stick to HTTP.
Many problems of the CA system can be mitigated by modern technologies
like Key Pinning and Certificate Transparency.

I think defaulting the net to HTTPS is a big step for more security and
I think Gentoo should join the trend here.

cu,

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Should Gentoo do https by default?

2015-03-27 Thread Hanno Böck
On Fri, 27 Mar 2015 15:14:02 -0400
Rich Freeman ri...@gentoo.org wrote:

 As has been pointed out, this is a moot issue for Gentoo.  However,
 I'm not aware of anybody who both offers a free certificate and will
 let you change your private key if it is compromised free of charge.

I think wosign does.
Haven't tested, but discussion on hacker news indicates revocation is
free [1].

And yes, the startssl behaviour regarding revocation is not good...


[1] https://news.ycombinator.com/item?id=8982013

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Should Gentoo do https by default?

2015-03-27 Thread Hanno Böck
On Fri, 27 Mar 2015 19:18:24 +
Robin H. Johnson robb...@gentoo.org wrote:

  * Some with logins are mixed http/login-via-https, which makes them
vulnerable to ssl-stripping-attacks (e.g. wiki.gentoo.org)
 Are you sure about this? Everything on wiki should always redirect to
 SSL very early.

Sure about what?
When I call the wiki page I currently get:
http://wiki.gentoo.org/wiki/Main_Page

Clicking on login will redirect to https, but at that point an attacker
is already able to change this link.

 Enabled for the following sites now (copied from cfengine commit):

Great. (However I don't see that yet live - server restart needed or is
there some deployment process that has to happen first?)

  * Make sure all use modern HTTPS features, including:
   * OCSP Stapling
 SSLUseStapling is Apache 2.3+ only, and that isn't stable yet.

That's unfortunate, apache 2.2 is pretty outdated when it
comes to tls security.

   * A secure collection of cipher suites
 What's wrong with our present Ciphers?

Haven't checked them in detail, looks mostly fine. One issue: DH
ciphers with a small modulus (1024 bit). But that's unfixable within
apache 2.2, so same as above.

  (On the long term I think it would also be good to have downloads
  over https, but I'm aware that this is more difficult as it
  involves mirror operators that are not under direct control of
  gentoo infrastructure.)
 This is why we published signatures on as much as we can.

Yes, signatures are fine, but realistically they require manual
intervention and not everyone will do that. Defaulting to https is a
very usable way to make malicious downloads less likely. Signatures
should stay as an additional protection measure.

 Users behind firewalls that block HTTPS are now going to be blocked
 from Gentoo services.
 
 Last time we proposed going HTTPS-by-default, there was complaint
 from users that were going to be locked out.

I would be very surprised if this is an issue any more.

These days pretty much all big players use https only (google,
facebook, twitter, github, ...). You can't really use the
mainstream internet if your firewall blocks https.

 We're still limited when it comes to services that need wildcards for
 the service. We have one such presently, and I hope we don't get more:
 Bugzilla, for attachments. (which are served at a different hostname
 that can't access your base bugzilla cookies even the attachment
 contains javascript that runs).

I have hopes that Let's encrypt will also allow free wildcards, but
that seems to be undecided yet.
But wildcards aren't super-expensive. One can e.g. get a validation by
startssl for an unlimited number of wildcards for a year, I don't
remember the exact price but it was in the 100-200$ range.

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



[gentoo-dev] Last rites: app-portage/portage-mod_jabber, media-sound/moodbar

2015-02-08 Thread Hanno Böck
# Hanno Boeck ha...@gentoo.org (08 Feb 2150)
# Dead upstream, will be removed in 30 days if nobody
# complains.
app-portage/portage-mod_jabber

# Hanno Boeck ha...@gentoo.org (08 Feb 2150)
# Dead upstream, will be removed in 30 days if nobody
# complains.
media-sound/moodbar


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Re: Last rites: app-portage/portage-mod_jabber, media-sound/moodbar

2015-02-08 Thread Hanno Böck
On Mon, 09 Feb 2015 01:33:28 +1100
Michael Palimaka kensing...@gentoo.org wrote:

 On 09/02/15 00:27, Alan McKinnon wrote:
  I use this, it builds without errors and works well with Amarok.
  
  Please leave it in the tree for as long as it functions correctly.
 
 I'd like to keep this too.

Okay, I hadn't expected that this even works, because its last release
was ages ago.

Michael: Do you want to add yourself as maintainer and unmask it?


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



[gentoo-dev] Packages up for grabs

2015-01-20 Thread Hanno Böck
Hi,

I'm listed on a number of packages as the maintainer that I don't
really care about any more.
Please if you want to take any of them add yourself as maintainer and
remove me. What's left will be re-assigned to herds if they exist,
maintainer-wanted or if they're likely broken anyway just removed.


app-editors/bluefish
Editor for programming and HTML. Recently bumped to the latest version.
Some minor bugs open in bugzilla that could need some attention.

app-laptop/hdaps-gl
Trivial tool to detect movement sensor in thinkpad laptops. Didn't have
a release in a long time, but also no issues, so probably can stay like
it is.

app-portage/portage-mod_jabber
I'm pretty sure this doesn't work any more. Dead upstream. Will
p.mask/lastrite if nobody steps up (stepping up means likely being the
new upstream).

dev-perl/Math-Vec
random perl package, will re-assign to perl herd if nobody else takes
it.

dev-ruby/dbf
database import for ruby. Already assigned to ruby and geoscience herd
where it can stay.

dev-ruby/GeoRuby
Already assigned to ruby and geoscience herd where it can stay.

media-gfx/pngnq
There's a trivial automake issue open in bugzilla which I will likely
just fix before giving it away, other than that will re-assign to
maintainer-wanted if nobody takes it.

media-sound/moodbar
This was used by amarok to display a colorful moodbar for audio files.
It depends on gstreamer 0.10, don't know if this will go away anyway at
some point.


cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



[gentoo-dev] last rites: dev-libs/libgeier

2015-01-03 Thread Hanno Böck
# Hanno Boeck ha...@gentoo.org (03 Jan 2015)
# Was a dependency of taxbird which has been replaced by
# geierlein. As this requires yearly changes it's unlikely
# it has any use for anyone. Masked for removal.
dev-libs/libgeier


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



[gentoo-dev] last rites: dev-libs/libgeier

2015-01-03 Thread Hanno Böck
# Hanno Boeck ha...@gentoo.org (03 Jan 2015)
# Was a dependency of taxbird which has been replaced by
# geierlein. As this requires yearly changes it's unlikely
# it has any use for anyone. Masked for removal.
dev-libs/libgeier


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



[gentoo-dev] Last rites: app-emulation/wine-doors

2015-01-03 Thread Hanno Böck
# Hanno Boeck ha...@gentoo.org (03 Jan 2015)
# dead upstream, masked for removal
app-emulation/wine-doors

If anyone wants to fix this: It requires downloads from upstream's
webpage, so it's likely impossible to take over without replacing
upstream entirely.

Open bugs:
https://bugs.gentoo.org/show_bug.cgi?id=519270
https://bugs.gentoo.org/show_bug.cgi?id=277491

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] rfc: New global USE flag called ios, not same as ipod ?

2011-03-29 Thread Hanno Böck
Am Tue, 29 Mar 2011 06:23:04 +0300
schrieb Samuli Suominen ssuomi...@gentoo.org:

 The magic number is often 5, this is 4 but it's only magic!

When I hear ios I first think of Cisco's IOS rather than Apple's. Is
this an issue?

-- 
Hanno Böck  mail/jabber: ha...@hboeck.de
GPG: BBB51E42   http://www.hboeck.de/

JETZT zu Ökostrom wechseln: http://atomausstieg-selber-machen.de



Re: [gentoo-dev] unbreaking net-print/foo2zjs

2011-03-07 Thread Hanno Böck
Am Sun, 27 Feb 2011 15:44:13 +0100
schrieb Paweł Hajdan, Jr. phajdan...@gentoo.org:

 As the package seems rather unmaintained, I'm going to wait for a
 while and check in the ebuild if nobody is against that.
 
 Any feedback is welcome, please let me know what you think.

I have a printer using foo2zjs and have my own ebuild for that. Though
my printer is black-white and thus doesn't need the whole color-profile
stuff and no firmware.

I thought about splitting the stuff to make maintaining easier. One
ebuild for the driver itself, one for the color profiles and one for
the firmwares.


-- 
Hanno Böck  mail/jabber: ha...@hboeck.de
GPG: BBB51E42   http://www.hboeck.de/



[gentoo-dev] la-file removal and || die

2010-11-01 Thread Hanno Böck
Just stepped upon a bug on a .la-file-removal-action that I'd like to share so 
others don't repeat that bug if we'll soon mass-add la-file-removal-code to 
ebuilds.

file-roller-2.32.0.ebuild has these lines:

find ${ED}usr/$(get_libdir)/nautilus -name *.la -delete \
|| die la file removal failed

This will die if the directory in place is not found. Unfortunately, this can 
be the case here as file-roller has a use-flag nautilus and the above 
directory only get's created if this flag is set.

I don't know if there's any valid reason to add || die to the la-file-removal-
command. Anyway, the already proposed eutils-function for lafile-removal would 
probably be the best way to avoid such problems for good.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] New license: nauty

2010-10-24 Thread Hanno Böck
Am Friday 22 October 2010 schrieb Thomas Kahle:
 The nauty license *does* restrict the cost of redistribution.  So what
 is it? An EULA?

Then it's probably just nothing according to our icense-groups. We don't 
have any need to have every license in any license-group.

EULA is for licenses where we need explicit agreement from the user. Nothing 
in the naugty-license indicates that, so it doesn't fit in any of our license 
groups.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] New license: nauty

2010-10-21 Thread Hanno Böck
Am Friday 22 October 2010 schrieb Robin H. Johnson:
 It's DFSG non-free because it contains a restriction on use (that
 military item) and sale.
 
 We're good to have it in MISC-FREE ourselves, as redistribution and
 everything else is free.

Erh, no. MISC-FREE is for free and open source software and is more or less 
the same as Debians free software guideline. That's the whole purpose of it.

It can go to BINARY-REDISTRIBUTABLE. If you wanna make a list of licenses that 
are more or less free with restrictions (however you define that), I'm fine 
with that, but I'd like to keep everything that's indirectly in the @FREE-set 
to be just that.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] nsbrowser plugins

2010-08-11 Thread Hanno Böck
Am Dienstag 10 August 2010 schrieb Paweł Hajdan, Jr.:
 Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins.
 However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what
 many software projects (including Chromium) target.
 
 Why are we using nsbrowser/plugins instead of mozilla/plugins, and how
 relalistic would it be to switch to mozilla/plugins?

The optimal approach would be some kind of standard for things like this. If 
you are already in contact with chromium developers, you might want to start 
such an initiative.

If it would be written in the FHS or something alike, it'd probably be easier 
to convince all browser vendors and distributions to stick to one general 
directory.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Hanno Böck
vpx for supporting googles vp8 codec used in webm.

At the moment this is only mplayer and ffmpeg, but it's pretty obvious that 
apps supporting vp8 will start popping up everywhere (currently working on 
arista ebuild which will support it).

Though we might discuss if vpx is really a good name or it shouldn't be vp8.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Looking for courier maintainers...

2010-03-06 Thread Hanno Böck
Am Samstag 06 März 2010 schrieb Samuli Suominen:
 Do we have any Courier maintainers?

I sort-of maintained courier in the past, although due to the number of issues 
and the complexity, I hesitated to add myself as a maintainer.
I'll take care of the security issue and try to get that handled with 
upstream.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] news regarding mysql 5.1 incomplete

2010-02-24 Thread Hanno Böck
Hi,

Just noticed yesterday an issue with the upgrade documentation in the news 
regarding mysql 5.1 and revdep-rebuild.

It suggests running
# revdep-rebuild --library libmysqlclient.so.15
but this is not enough. mysql has more than one library and not all 
applications link against the main lib.

On a server system (which uses as-needed), I encountered two packages (apr-
util and mysql-python) only linking against libmysqlclient_r.so.

So at least when mysql 5.1 gets stable, we should correct this.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Recent lists mail loss

2010-02-03 Thread Hanno Böck
There's a german statement from the Nix Spam RBL.

http://www.heise.de/ix/foren/S-Re-Mailinglisten-Bestaetigungs-Email-an-
Spamtrap-legt-Gentoos-Mailinglisten-
lahm/forum-48292/msg-18035095/read/showthread-1/

As many here probably can't read german, the important points are:
- RFC 3834 defines headers for automatically sent mails, seems our mailing 
list software doesn't do that - but robbat2 commented in his blog is already 
in contact with upstream about that.
- they claim that nobody contacted them directly and their automatic delisting 
method was not used.

I'm personally using the mentioned RBL on my servers and I read some articles 
and heared some talks from their operators and generally think they are doing 
good work, so I wanted to share that.

cu,
-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] openssl 1.0.0 quick test

2010-01-30 Thread Hanno Böck
Hi,

I recently installed the masked openssl 1.0.0_beta5 and tried to rebuild 
everything against the new version of openssl.

I know it's probably not very urgend to get on that, but I thought others 
might be interested in the status.
- php fails, fix is trivial. I've sent it upstream and it got already applied 
to upstream svn:
http://bugs.php.net/bug.php?id=50859
- wvstreams fails, fix also trivial and sent upstream, no reply yet:
http://code.google.com/p/wvstreams/issues/detail?id=27
- ruby fails (both the 1.8/1.9 versions from the tree and the latest from the 
ruby-overlay), fix seems to be non-trivial. There is some upstream work on it 
I haven't tested:
http://redmine.ruby-lang.org/issues/show/2022

So all in all it's not that much. I'll leave it up to the maintainers of php 
and wvstreams if they want to patch their packages or wait till upstream fixes 
arrive.

cu,

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] last rites: games-util/dzip

2010-01-22 Thread Hanno Böck
Am Mittwoch 20 Januar 2010 schrieb Michael Sterrett:
 You can look at the discussion at
 http://bugs.gentoo.org/show_bug.cgi?id=288905 but with the last
 release in 2003 it seems like a pretty dead package.

As we seem to have nothing else that can open dzip files and they are used in 
the wild, I think we should keep it.

I committed 2.9-r3 which fixes the zlib issue, I also added a patch for 64 bit 
support and an ~amd64 keyword.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] last rites: games-util/dzip

2010-01-20 Thread Hanno Böck
Am Mittwoch 20 Januar 2010 schrieb Michael Sterrett:
 # Last release in 2003.  Doesn't work with latest zlib.
 # masked for removal on 20100219
 games-util/dzip

It works with latest zlib, at least on my system.

I'd like to rescue it, though I can't see a problem, can you open bugs for 
potential issues and assign them to me?

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Documentation licenses and license_groups

2010-01-07 Thread Hanno Böck


Am Dienstag 05 Januar 2010 schrieb Ulrich Mueller:
 Licenses for Works of Opinion and Judgment (maybe omit this group?):
 
CCPL-Attribution-NoDerivs-3.0 (there's only 2.5 in ${PORTDIR}/licenses/)
(GNU Verbatim Copying License - not yet in ${PORTDIR}/licenses/)

I think they don't belong there - no matter what the fsf thinks (I think their 
views about different freedoms on software and on documents are a bit weird), 
I think we should have a free license set which guarantees the four 
freedoms, no matter if it's software or documentation.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] QA last rites for app-emulation/uae

2010-01-07 Thread Hanno Böck
Am Dienstag 05 Januar 2010 schrieb Diego E. Pettenò:
 # Diego E. Pettenò flamee...@gentoo.org (05 Jan 2010)
 #  on behalf of QA team
 #
 # Fails to build with different configurations (bug #205050,
 # open January 2008, with patch and bug #262243, open
 # March 2009).
 #
 # Removal on 2010-03-06
 app-emulation/uae

I'll try to rescue that one.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Some ideas on the licensing issue

2010-01-07 Thread Hanno Böck
Hi,

Had some more thoughts about that licensing issue and wanted to make some 
suggestions.

I think the GPL-compatible set makes barely sense. The problem with it is, as 
stated by various people, that we have different GPLs. GPL2 and 3 are 
incompatible, so it doesn't mean GPL-compatible are all licenses that can be 
mixed together. I don't know how/if we should resolve this.

Difference between OSI and FSF approved: AFAIK, I once read about one license 
that OSI approved and FSF not. Do we have any affected packages in the tree 
where FSF and OSI differ? I think the definitions of FSF and OSI are pretty 
much the same, their differences are more on a political level, not on a 
licensing one. So I'd like it much more to have one big This is free and open 
source software set.

For documentation, we may want to have another set? I'll add one with the well 
known free documentation licenses (FDL, CC by, cc by-sa). If we decide to go 
some other way, we can throw it away, but I wanted to start something ;-)


What bites me is the man-pages issue. Is it really the case that there's no 
free (as in freedom) man-pages package? Maybe then we should provide an option 
to install the base system without man-pages?

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Documentation licenses and license_groups

2010-01-07 Thread Hanno Böck
Am Donnerstag 07 Januar 2010 schrieb Ulrich Mueller:
 So the plan is:
 - Add GPL-1 and LGPL-2 to @GPL-COMPATIBLE
 - Add a new group @FSF-APPROVED-OTHER containing the following:
 Arphic
 CCPL-Attribution-2.0
 CCPL-Attribution-ShareAlike-2.0
 DSL
 FDL-1.1 FDL-1.2 FDL-1.3
 FreeArt
 GPL-1 GPL-2 GPL-3
 OFL-1.1
 OPL
 
 If there are no objections, I'll commit this in the next days.

I already went ahead and committed two new sets - FREE-DOCUMENTS and MISC-
FREE.

The above ones could probably be all added to FREE-DOCUMENTS.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Some ideas on the licensing issue

2010-01-07 Thread Hanno Böck
Am Donnerstag 07 Januar 2010 schrieb Ulrich Mueller:
  On Thu, 7 Jan 2010, Hanno Böck wrote:
 
  I think the GPL-compatible set makes barely sense. The problem with
  it is, as stated by various people, that we have different GPLs.
  GPL2 and 3 are incompatible, so it doesn't mean GPL-compatible are
  all licenses that can be mixed together. I don't know how/if we
  should resolve this.
 
 So what do you suggest? Remove GPL-COMPATIBLE and move everything
 into FSF-APPROVED?

Yeah, I think that's reasonable.

I'm currently in contact with FSF-people so I hope we can clarify if all the 
looks free but is not mentioned on the FSF homepage-licenses.

  For documentation, we may want to have another set? I'll add one
  with the well known free documentation licenses (FDL, CC by, cc
  by-sa). If we decide to go some other way, we can throw it away, but
  I wanted to start something ;-)
 
 Is your FREE-DOCUMENTS meant to include things like fonts, or do we
 need another group for them?

I was unsure about that but I'd say yes unless we want to complicate things 
more than neccessary. I already put in one font license.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc

2009-12-11 Thread Hanno Böck
Am Freitag 11 Dezember 2009 schrieb Christian Faulhammer:
 George Shapovalov (george) geo...@gentoo.org:
Modified: use.local.desc
Log:
added local flags for new version of net-fs/coda
 
  Please don't add local flags to use.local.desc anymore.  They are now
 maintained in metadata.xml file.

Is this a wise idea?
Because, when I choose a new local flag, I try to stick with ones other 
packages already use (to make possible future transition to a new global one 
easier). This isn't possible any more if there's no central place for them.
Maybe something like use.local.desc that is autogenerated?

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Lastrite: KDE3 applications with bugs and KDE4 replacements.

2009-10-26 Thread Hanno Böck
Am Sonntag 25 Oktober 2009 schrieb Samuli Suominen:
 # Samuli Suominen ssuomi...@gentoo.org (25 Oct 2009)
 # Replaced by:
 #
 # =media-gfx/digikam-0.10
 # kde-base/gwenview
 # =media-gfx/kphotoalbum-4
 # =media-plugins/kipi-plugins-0.6
 #
 # Masked for removal in 30 days.
 media-libs/libkdcraw
 =media-gfx/digikam-0.9*
 =media-gfx/kphotoalbum-3*
 media-gfx/gwenview
 =media-plugins/kipi-plugins-0.1*
 media-libs/libkipi
 media-libs/libkexiv2

gwenview from kde4 is no replacement for the single app gwenview. It's a 
completely different (I assume 99% rewritten) app and they don't have much in 
common beside that both are for image viewing.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] python-wrapper breaks init scripts

2009-10-04 Thread Hanno Böck
Hi,

I just stepped over a problem with the new python-wrapper. If I interpreted 
the changelogs correctly, since eselect-python-20090801 /usr/bin/python is no 
longer a symlink, but a wrapper.

I find this a questionable idea simply for the overhead it causes, but it 
seems that this breaks all init-scripts using start-stop-daemon for python 
scripts.

Example:
http://bugs.gentoo.org/show_bug.cgi?id=286191

(same issue happens with some self-written python daemons we're using on our 
servers)

I don't know what the reasons were for the change from symlinks to a wrapper, 
but if it should stay the way it is, we need a fix for those issues.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Lastrite: app-misc/sdricoh_cs

2009-08-12 Thread Hanno Böck
(I know this mask is quite old, but I haven't sent correct last rites back 
then, so doing this now)

# Hanno Boeck ha...@gentoo.org (22 Jan 2009)
# This has been included in kernel 2.6.27 and shouldn't be used
# any more. Will remove within a month, please contact me if you
# think it should stay.
app-misc/sdricoh_cs


-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Qt3 deprecation

2009-07-28 Thread Hanno Böck
While I fully understand that people want to deprecate old cruft, I assume 
this is far too early. (just think back how long it took us to deprecate 
gtk+-1)

I'm still on kde 3 and my previous three attemps to switch to kde 4 all ended 
up in the conclusion that kde 4 is far from being stable yet. It has tons of 
regressions.

The amount of qt3 apps not having a sane or just no qt4 port yet is probably 
enormous. I also maintain such packages.


Though we don't know what the situation is in 6 months, I'd assume that 
there's no chance we can consider qt3 fully deprecated then.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: sci-geosciences/osm2mp

2009-05-26 Thread Hanno Böck
osm2mp was a tool needed for conversion of openstreetmap maps into an 
intermediate format, which could be used for further conversion into garmin 
maps with mkgmap.

Latest versions of mkgmap accept osm files as an input, osm2mp is not 
maintained and imho not of any use nowadays, so I'll remove it soon.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de
http://ausdenaugenausdemsinn.de - Kein Sicherheitsrabatt für CO2-Speicher
http://tinyurl.com/dceu73 - Internetzensur stoppen!

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: app-misc/sdricoh_cs

2009-01-22 Thread Hanno Böck
Hi,

sdricoh_cs is a module for a sd/mmc/memorystick-card-reader found in some 
laptops. Upstream-kernel includes it since 2.6.27. So the ebuild is pretty 
much obsolete, has an open QA bug I don't intent to fix any more and can 
probably just go away.

# Hanno Boeck ha...@gentoo.org (22 Jan 2009)
# This has been included in kernel 2.6.27 and shouldn't be used
# any more. Will remove within a month, please contact me if you
# think it should stay.
app-misc/sdricoh_cs


-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] status of ruby 1.8.7?

2008-12-17 Thread Hanno Böck
Hi,

We have ruby 1.8.7 in the tree masked since April.

# Richard Brown rbr...@gentoo.org (16 Apr 2008)
# Masked for test
=dev-lang/ruby-1.8.7*

There's no tracker bug or anything alike about the status of unmasking, so I 
wanted to ask what's the status here.


Beside, I'd like to repeat that I think it's a very bad idea to add new 
packages to package.mask for testing without any further information. 
Usually a tracker bug is a good idea, but any other note where to find 
information what needs to be done to get things ready is fine.


-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Package for grab: libzzub and aldrin

2008-11-18 Thread Hanno Böck
Hi,

Cite
Aldrin is an open source modular music sequencer/tracker for the GNU/Linux 
operating system. It features a flexible audio routing system commonly found 
in expensive audio software, enabling you to mix, split, mutilate and modify 
audio signals emitted by software synthesizers and samples.

I once added an ebuild for aldrin and zzub (the library aldrin is mostly based 
on) to the tree, though it needs a lot of work (use-flags for various 
features, try to reduce the usage of bundled libraries, fixes for as-needed).
At the moment the one in the tree doesn't compile and an upstream bump is 
pending.

Though my interest in the package is low, so is there anyone willing to grab 
it?

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Unmasking of qt 4.4?

2008-08-11 Thread Hanno Böck
Hi,

I'm maintaining a package of merkaartor in gentoo, of which the latest version 
requires qt 4.4. I'll mask that for now, but I'm not really happy with that.

I wanted to ask what are the showstoppers for qt 4.4 to get unmasked. The mask 
is commented with:
Masked for testing, various dependencies still need to be updated...

I don't like masked for testing comments (we have far to many of them), as 
it basically tells nothing. Testing what? How long?
For the dependencies, I think this isn't a showstopper either, as if you don't 
have split dependencies on qt, it'll just take the metapackage and everything 
is like before.

So question, what are the showstoppers for qt 4.4? And more general comment, 
especially on important packages that many people rely on, please provide 
more informative comments in package mask, e.g. bug numbers.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] unrecognized option warning

2008-06-21 Thread Hanno Böck
Hi,

I was pointed by a user that the gimp ebuilds configure run produces warnings 
about unrecognized options.
Looks like this:
configure: WARNING: Unrecognized options: --with-hal, --without-wmf

A short grep over my portage logdir showed lots of these in various packages. 
My suggestion would be that we add a QA warning to portage for every econf 
call causing such a warning.

Probably there are mostly two reasons when such a warning occurs:
- The ebuild writer thinks there must be an option for en/disabling foo, 
though adding use_enable/use_with foo, although it's autodetected. We have an 
automagic dep.
- The option was there in previous versions, but got removed (i.e. is now 
default / can't be built without foo any more).

Both cases should be fixed and may hide other bugs, though a QA warning would 
be good.

Thoughts?

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Automagic dependencies in gegl

2008-05-01 Thread Hanno Böck
Hi,

Recently, GIMP got it's first development version based on gegl.

Now, gegl has 13 optional dependencies that could be use-flagged. The pity is, 
it has no configure-option for most of them, they are autodetected.
(It's about gtk, ruby, lua, cairo, pango, libpng, openexr, rsvg, sdl, 
asciidoc, enscript, graphviz and ffmpeg)

My experience with the gimp developers in the past was that they weren't very 
pleased by bugs about automagic deps and I assume if I post them without 
patches, they'll get closed immediately. Now I always avoided to dig too deep 
into autotools, so I don't feel skilled enough for this task.

Is there some brave gentoo dev (or non-dev, doesn't really matter) 
volunteering to send patches to gegl-upstream?


Beside, I'm asking myself how to handle this situation. Hard-enable them all 
as long as there are no patches? Let the automagic go in the tree? Opinions 
welcome.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] courier ebuilds for testing

2008-04-09 Thread Hanno Böck
Hi,

Our in-portage courier ebuilds are pretty much outdated and assigned to 
maintainer-needed.

A friend of mine, Bernd Wurst, has created a couple of up-to-date ebuilds and 
maintains them. I'm thinking about proxy-maintaining them and would like to 
commit them soon. Though they are pretty much only tested by us on our 
servers and we don't use the webmail, webadmin and fax services.

http://svn.schokokeks.org/repos/overlay/trunk/mail-mta/
http://svn.schokokeks.org/repos/overlay/trunk/net-libs/

So if you use courier, please test them and contact me with bug reports or 
success stories (cc to [EMAIL PROTECTED] ).

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] How to force homedir on enewuser

2008-01-17 Thread Hanno Böck
Hi,

Following situation: Older mailman ebuilds used to set the mailman user home 
to /usr/local/mailman (which is obviously wrong).

Now with the new mailman ebuild, various directories are configurable.

The mailman user is created with the enewuser macro. Now, the problem is that 
enewuser just exits with zero if the user already exists. Thus the old 
homedir is kept.

What is the correct way to handle this? I'd suggest that enewuser might get 
some force-parameter that tells it to delete and recreate the user if it 
already exists. Thoughts?

(If noone comes around with a better idea, I'll open a bug with a feature 
request within a few days)

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] net-mail/mailman-2.1.9-r2: Request for testing

2007-11-26 Thread Hanno Böck
Hi,

The mailman ebuild was a pain in the past, installing to non-fhs-locations 
(/usr/local), doing lot's of strange stuff, not able to use etc-update...

mailman-2.1.9-r2 tries to fix lot's of those issues, it's much more 
configurable through some variables. It's currently masked, but yesterday I 
committed a bunch of changes and now I'm pretty satisfied with it.

So I'd like to unmask it soon. Please, if you're using mailman test it, tell 
me if it suits your needs or just give me feedback like worksforme, I 
actually don't have a clue how many people really use this ebuild.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/compiz-bcop: metadata.xml Manifest compiz-bcop-0.6.0.ebuild ChangeLog

2007-10-24 Thread Hanno Böck
Am Mittwoch 24 Oktober 2007 schrieb Donnie Berkholz:
 Both S and src_compile() are the defaults, and this is not the only
 compiz ebuild committed today where that is the case.

All done now I think.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/compiz-fusion-plugins-main: compiz-fusion-plugins-main-0.6.0.ebuild metadata.xml ChangeLog Manifest

2007-10-23 Thread Hanno Böck
Am Mittwoch 24 Oktober 2007 schrieb Petteri Räty:
 Hanno Boeck (hanno) kirjoitti:
  hanno   07/10/23 22:33:31
 
  S=${WORKDIR}/${P}

 This is the default.

  src_compile() {
  econf `use_enable jpeg` || die econf failed
  emake || die make failed
  }

 I think it's more common to use the $() syntax for use_enable.

I'll do it later today.

They seem to be good candidates for new repoman checks, as we probably have 
tons of them in the tree.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] QA question, undefined reference to _getshort

2007-10-18 Thread Hanno Böck
Any volunteers for writing a patch? :-)

Upstream is very cooperative, if you want to work together with them.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Last rites: www-client/planet

2007-10-13 Thread Hanno Böck
Am Mittwoch 10 Oktober 2007 schrieb Dawid Węgliński:
  www-client/planet
[...]
 Anything to use instead?

No ebuild for it, but blog harvester is an alternative:
http://astroblog.spaceboyz.net/harvester/

it's suggested to use svn version.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-mail/mailman: ChangeLog mailman-2.1.9-r2.ebuild

2007-09-27 Thread Hanno Böck
Am Donnerstag 27 September 2007 schrieb Donnie Berkholz:
 This thing is packed with quoting issues for S, D and FILESDIR, and the
 pkg_* functions don't respect ROOT.

Quotes done. About pkg_ and ROOT: Didn't find any issues here. python_mod_* 
seems to care about that itself. Found one issue in src_install, but none in 
pkg_*


-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/gimp-help: ChangeLog gimp-help-0.13.ebuild

2007-09-27 Thread Hanno Böck
Guys, it's nice that you have so interesting discussions, but let me just 
state that I haven't written this code. I just did a trivial copy-over-bump.

If anyone wants to improve the ebuild, feel free do go ahead and commit your 
changes.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] SSL-Certificates and CAcert

2007-09-27 Thread Hanno Böck
Hi,

Everytime I'm sending out a mail with my gentoo.org-address, I get 
this certificate may be unsecure message. Gentoo mailserver (and forums, 
bugzilla and probably many more) use self-signed ssl-certificates.

Well, I hope I don't have to tell that self-signed certs are not really good 
security policy. Imho, having those pay lots of $/€-certs also isn't a very 
good option, because obviously security for the ones who pay a lot isn't a 
good idea either.

I think most of you know that there's CAcert, a free certificate authority. 
While it's sadly not free in a free software sense (their own software 
isn't released under a free license, though I hope that will change at some 
point in the future), it uses a web-of-trust-based concept for trust and 
issues certificates with no costs.

I think compared to self-signed, having cacert-certificates would be a big 
improvement. Many other free software projects (and more and more other 
pages) use cacert, so it becomes more and more likely that people will 
already have the cacert-root-cert installed.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


  1   2   >