10.13 builder on our BuildBot is failing

[Zero King]

Hi,

Our 10.13 builder on build.macports.org is failing with:

twisted.spread.pb.RemoteError: [Errno 23] Too many open files in system: 
'/opt/bblocal/var/buildworker/ports/ports-10_13_x86_64-watcher'

--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: poppler, security updates in general...

[Clemens Lang]

Hi,

On Wed, Jan 10, 2018 at 04:39:05PM +0100, Rainer Müller wrote:
> > I think you’re referring to Repology:
> > 
> > https://repology.org
> > 
> > No CVE linkages that I can see there.  That would be a valuable
> > resource though.

That's the one, thanks.

> I do not think Repology would offer that because distributions often
> backport fixes to older versions. Therefore you cannot tell from the
> version number alone whether the software is still vulnerable.

Correct, repology doesn't solve this problem alone, but it may solve the
problem of finding the "canonical" name of a package in a CVE database,
which is the first step to tracking which ports have open CVEs.

Whether a CVE was already fixed in MacPorts of course needs to be
tracked separately from that.

> Not sure a full-blown security tracker is feasible compared to
> something like a simple website per port on which users could flag it
> as vulnerable for review by the maintainer.

Or even just a website that lists CVEs that affect the versions
currently in MacPorts. We don't backport security fixes very often, we
mostly just update versions.

-- 
Clemens

Re: GSOC 2018 org application period has begun

[Clemens Lang]

Hi,

On Wed, Jan 10, 2018 at 08:36:39AM +0530, Jackson Isaac wrote:
> That's great :) I'll help you out. Probably its time for me to become
> a Mentor now ;)
> 
> > Let me know what you think and also, if any other criteria MacPorts
> > has. I'd be happy to volunteer. Could use someone as backup admin
> > too.
> 
> I can be the backup admin. Clemens used to be the backup admin in the
> previous years. I'll wait for his reply before confirming.

I'll happily pass the backup admin torch to you. You've seen how things
work in GSoC, I'm convinced you don't need me as a backup admin to run
this :)

-- 
Clemens

Re: libressl vs openssl

[Jan Stary]

On Jan 10 11:02:46, neum...@wu.ac.at wrote:
> Am 09.01.18 um 18:24 schrieb Perry E. Metzger:
> > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary  wrote:
> > > Hi Jeremy,
> > > 
> > > > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston
> > > > Sequoia wrote:
> > > > > There are some things that I want to do to the port (and
> > > > > OpenSSL)
> > > It would be very nice if all ports currently depending on openssl
> > > would build against libressl, and we could get rid of openssl
> > > in favor of the way-superior libressl (until Apple replaces
> > > it system wide. ha ha ha.)
> > I'm not sure I agree with the claim that libressl is necessarily
> > better.
> i would as well be cautions with the term "superior", at least when the
> criteria are not clear.

So here is a few, as a start:

Wraps malloc() -- and every other normal C function -- in its
VERYOWNBUGGY_malloc() that never frees, thus sabotaging any
memory-exploit mitigations the OS migth be doing?

Has its own snprintf() and memcmp() etc, with an _almost_ identical
interface and return values, but not quite?

Has its own broken random generator?

Nests #ifdefs to depth 17?

Has NO_OLD_ASN1 and NO_ASN1_OLD compile options
doing different things?

Defines a union of a couple different ints, calls accept(),
then inspect the different union members to determine which ones were
overwritten by the kernel, to find out what the size of socklen_t is?

Contains tens of thousands of lines of dead code
to support VMS or MS Visual C 1.52?

> In the past i have provided support for OpenSSL 1.0.* and 1.1.* and
> LibreSSL 2.6.3 and 2.6.4 for non-trivial projects , and from my experience
> this is not a simple drop-in replacement in general.
> One pain is that OpenSSL changed some calls between 1.0 and 1.1,

Could you please elaborate on the technical details?
Or point to some write-up on that?

> and another one is that LibreSSL claims to be OpenSSL 2.*
> (via |OPENSSL_VERSION_NUMBER|)
> which confuses source code that has to compare for version numbers
> for the above reasons.

Comparing a version number is not the hard part, right?
For example, this is how we currently unconfuse libevent:
https://github.com/macports/macports-ports/blob/master/devel/libevent/files/patch-libressl.diff

> The process is doable (see e.g. HardenedBSD [1], OpenBSD 5.6),

Well, OpenBSD is where it came from.

> but cooperation with upstream projects
> is probably required for some packages.

Definitely; I am going through the ports that depend on SSL
trying to sort it out at least in the ports I use. Some work
just fine with LibreSSL, some need patches, some just need to
be unconfused about the version.


Jan

Re: libressl vs openssl

[Jan Stary]

On Jan 09 09:40:23, bl...@orcaware.com wrote:
> https://boringssl.googlesource.com/boringssl/
> 
> "Although BoringSSL is an open source project, it is not intended for general 
> use, as OpenSSL is. We don't recommend that third parties depend upon it. 
> Doing so is likely to be frustrating because there are no guarantees of API 
> or ABI stability.”
> 
> If projects link statically against an SSL library, then BoringSSL maybe 
> fine, but probably not as a shared library used by many packages.

As opposed to a static library used by many packages?

Re: libressl vs openssl

[Jan Stary]

On Jan 09 12:24:22, pe...@piermont.com wrote:
> On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary  wrote:
> > Hi Jeremy,
> > 
> > > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston
> > > Sequoia wrote:  
> > > > There are some things that I want to do to the port (and
> > > > OpenSSL)  
> > 
> > It would be very nice if all ports currently depending on openssl
> > would build against libressl, and we could get rid of openssl
> > in favor of the way-superior libressl (until Apple replaces
> > it system wide. ha ha ha.)
> 
> I'm not sure I agree with the claim that libressl is necessarily better.

Please read and see the following to convince yourself that
it is desirable to replace OpenSSL with LibreSSL if at all possible.

https://www.openbsd.org/papers/bsdcan14-libressl/index.html
https://www.openbsd.org/papers/eurobsdcon2014-libressl.html
https://www.youtube.com/watch?v=GnBbhXBDmwU
https://www.youtube.com/watch?v=WFMYeMNCcSY
https://www.tedunangst.com/flak/post/worst-common-denominator-programming
https://marc.info/?l=openbsd-misc=139698608410938=2
https://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
https://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Personally, I like the socklen_t bit the most:

  You want to create a variable the same size as socklen_t. One fairly
  obvious solution would be to declare a variable of type socklen_t.
  That's not how OpenSSL does things, however. Instead, let's create
  a union of a couple different ints, call accept(), then inspect the
  different union members to determine which ones were overwritten by the
  kernel. Oh, and don't forget to check for big endian versus little endian. 

Jan

Re: poppler, security updates in general...

[Rainer Müller]

On 01/10/2018 04:00 PM, Craig Treleaven wrote:
>> On Jan 10, 2018, at 4:20 AM, Clemens Lang  wrote:
>> That's correct. It would be nice if we had some tooling that could check
>> for CVEs we haven't fixed yet. If you would like to grab some of the
>> existing open source tooling and modify it so it uses the MacPorts ports
>> tree as input, that would be great.
>>
>> A while ago somebody on the list had a project that would import MacPorts
>> ports into a format common for all package managers (and provide a
>> webservice + website for that). Maybe that could be used here?
> 
> I think you’re referring to Repology:
> 
> https://repology.org
> 
> No CVE linkages that I can see there.  That would be a valuable resource 
> though.

I do not think Repology would offer that because distributions often backport
fixes to older versions. Therefore you cannot tell from the version number alone
whether the software is still vulnerable.

Not sure a full-blown security tracker is feasible compared to something like a
simple website per port on which users could flag it as vulnerable for review by
the maintainer.

Rainer

Re: poppler, security updates in general...

[Craig Treleaven]

> On Jan 10, 2018, at 4:20 AM, Clemens Lang  wrote:
> 
> Hi Perry,
> 
> - On 9 Jan, 2018, at 18:27, Perry E. Metzger pe...@piermont.com wrote:
> 
>> I note the version of poppler we're shipping is pretty old, and that
>> there are CVEs outstanding against it.
>> 
>> Am I correct in assuming that as things stand, we mostly depend on
>> port owners to track security updates on behalf of the project and
>> that there isn't a security officer or any such thing? (Not
>> complaining, just seeking clarification.)
> 
> 
> That's correct. It would be nice if we had some tooling that could check
> for CVEs we haven't fixed yet. If you would like to grab some of the
> existing open source tooling and modify it so it uses the MacPorts ports
> tree as input, that would be great.
> 
> A while ago somebody on the list had a project that would import MacPorts
> ports into a format common for all package managers (and provide a
> webservice + website for that). Maybe that could be used here?

I think you’re referring to Repology:

https://repology.org

No CVE linkages that I can see there.  That would be a valuable resource though.

Craig

Re: libressl vs openssl

[Jan Stary]

Hi Jeremy,

> > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston Sequoia wrote:
> > > There are some things that I want to do to the port (and OpenSSL)

what is the strategy with the libressl port as opposed to libressl-devel?
Currently, libressl is 2.5.5 and libressl-devel is 2.6.2.

I don't think upstream even considers "devel" releases in any sense,
a release is a release. Is there anything else from the port's view
that makes one of them "stable" and the other one "devel",
or is it just a name for previous and latest?

Jan

Re: reclaim and rleaves

[db]

On 15 Dec 2017, at 15:51, db  wrote:
> Shouldn't reclaim use rleaves instead of unrequested? As of now I have to 
> rerun reclaim in order to remove unnecessary ports.

Can anyone clarify why multiple runs of reclaim are necessary?

Re: poppler, security updates in general...

[Clemens Lang]

Hi Perry,

- On 9 Jan, 2018, at 18:27, Perry E. Metzger pe...@piermont.com wrote:

> I note the version of poppler we're shipping is pretty old, and that
> there are CVEs outstanding against it.
> 
> Am I correct in assuming that as things stand, we mostly depend on
> port owners to track security updates on behalf of the project and
> that there isn't a security officer or any such thing? (Not
> complaining, just seeking clarification.)


That's correct. It would be nice if we had some tooling that could check
for CVEs we haven't fixed yet. If you would like to grab some of the
existing open source tooling and modify it so it uses the MacPorts ports
tree as input, that would be great.

A while ago somebody on the list had a project that would import MacPorts
ports into a format common for all package managers (and provide a
webservice + website for that). Maybe that could be used here?

-- 
Clemens Lang