-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net-libs/iojs-1.7.1 version bump #95
Conversation
For the future: please state explicitly that you're the proxied maintainer, so I wouldn't unnecessarily check who to ping about the ebuild :). |
@mgorny apologies. I'm currently awaiting feedback from hardened-people (while downloading pentoo myself) |
!bundled-libs? ( | ||
>=net-libs/http-parser-2.3 | ||
>=dev-libs/libuv-1.4.2 | ||
>=dev-libs/openssl-1.0.1m[-bindist] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any sane reason to bundle those three? If it's just 'upstream has configure flags for it', then kill the flag and always use system libs. We allow bundling/static only in special cases (like to solve circular deps or when upstream is going to shout loud at people).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. One reason is that certain use-cases (containers, et al) benefit from a simpler binary. As of next version of iojs, it even has a fully static (libc included) representation. I felt that exposing this would be beneficial to the user, especially in gentoo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not beneficial. Nobody's going to track which packages randomly bundle vulnerable libraries. Security is our primary concern, convenience comes later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I am part of upstream I think I'm in a position to do something about that, hence the benefit. Also, the flag needs to be enabled which makes me assume the user knows what they're doing. We have a few issues (test failures) as a result of Gentoo having different versions of dependencies. I'm working on improving the test suite to have better resilience for said tests (openssl 1.0.2 and http_parser currently makes two tests if you're on 1.0.2 resp 1.4.x).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please prove me that the Gentoo Security team lists random packages bundling openssl in openssl GLSAs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't argue with that, but wouldn't security team then mark all iojs packages which bundles an older openssl with bundled-libs as vulnerable?
Since bundled-libs
is already in tree - shouldn't we think twice before removing it at least?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Security team can't keep a huge list of 'who bundles what in which version'. This simply is too much work.
Just because others screwed up hard, doesn't mean we should let things get even worse. I'm just one person, I can't watch everyone all the time :P.
@mgorny just pushed a new version. Still need to come to a resolution regarding |
Quick update: Vadim A. Misbakh-Soloviov just reported that hardened now builds this properly. Also, I've done some reading and gotten help from #gentoo-hardened as well as from blueness@g.o -- we won't be needing paxmark.sh. If there are no more outstanding comments, I'll rebase. |
I guess this is the point when you can rebase for final review :). |
Most important changes: - Updates metadata to add an active upstream - Split out building v8 to support hardened kernels - Support IUSE=debug to install a debug version of iojs - Sort inherit a-z - Add || die on in a few places - Replace static python2 calls with EPYTHON
@mgorny done. Edit: minor spelling issues in commit logs -- feel free to revise logs. |
def pkg_config(pkg): | ||
- cmd = os.popen('pkg-config --libs %s' % pkg, 'r') | ||
+ pkg_config = os.environ.get('PKG_CONFIG', 'pkg-config') | ||
+ cmd = os.popen(pkg_config + ' --libs %s' % pkg, 'r') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you upstreaming this? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and more.
Ready to merge? No need to rebase, it'll get squashed when applying. |
I'm all good if you are :) |
|
(Portage version: 2.2.18/cvs/Linux x86_64, signed Manifest commit with key EFB4464E!)
Version bump as well as a few improvements. I will add commits as the review progresses and rebase once I get enough LGTM's.
(Intended, see todo) changes from 1.6.3-r1:
This ebuild is also meant to land as nodejs-0.12.x once properly reviewed and landed. It should fix all open bugs of nodejs. I sincerely apologise to all nodejs users for leaving the ebuild out in the cold for a while - but my primary interests has lived with iojs for a while.
Open todo's: