[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo, golang
Seth Arnold
1267393 at bugs.launchpad.net
Thu Sep 17 02:09:14 UTC 2015
I reviewed juju version ff791983cd1a186e2e09878a37cf243f7f9eb734. The
review covered significantly less portion of the codebase than usual, and
should not be considered a security audit.
Juju 1.18.1 is in trusty-release
Juju 1.22.6 is in trusty-updates
Juju 1.22.1 is in vivid-release, meaning upgrades from updated trusty to vivid fail
Juju 1.22.6 is in wily
When were 1339770 1389326 1391276 fixed? Are they fixed in all supported
releases? There's no mention of any of these bug numbers in the published
changelogs:
https://launchpad.net/ubuntu/+source/juju-core/+changelog
These bugs were known to be dangerous in 2014 yet still caused extensive
damage in May, 2015. What allowed them to persist so long? What steps have
been taken to ensure future bugs of similar severity don't last unpatched
in production for so long?
In 1339770, in May 2015, it was mentioned that 1.18 was end-of-life and no
further updates could be prepared for it. 1.18.0 was released just 13
months earlier and 1.18.1 had been included in 14.04 LTS. Why was the 1.18
infrastructure torn down so shortly after including 1.18 in a release with
five-year support? Have there been any similar changes in process that
would prevent or delay issuing an update to the currently supported
versions of juju already in the archive?
It is currently impossible to upgrade from 14.04 LTS to 15.04 due to
incorrect version numbers. Has anyone else noticed this yet? When will
this be fixed? Are there any changes in process needed to ensure this
doesn't happen in the future?
Will the juju team be asking for an MRE? Is it anticipated that new series
(e.g., the 1.18 to 1.22 change) would be included as an MRE? What
processes are in place to test updates before including updates into the
archive? What processes are available to the security team to test
updates that we would prepare?
I had more trouble reading the Juju code this review cycle than last
review cycle -- the Facade indirection mechanism makes code navigating
harder. I'm worried about it for a few reasons:
- Strings to reference method names are brittle and can't be checked at
compile time. What methods are in place to ensure that these aren't
typoed?
- Generic args and return types defeat type checking. What ensures types
being returned or accepted have the desired properties?
- Java has had significant problems with their Reflection mechanism,
probably dozens of issues per year. At what points of a process
lifetimes is the Facade mechanism dynamic?
Here's a few issues I found:
- ./apiserver/apiserver.go logs passwords when tracing is enabled -- this
is fine IFF this is loudly documented somewhere obvious. Is it? It'd be
best to filter out passwords regardless.
- Chown() doesn't quote the user or group
- ./api/client.go WatchDebugLog() claims to read a line but looks like it
may read up to 4096 bytes -- is this correct?
- significant number of TODO comments; is there a method in place to find
unowned comments and assign them somewhere? is there a process in place
to ensure they get revisited?
- Which versions of the client work with which versions of the servers?
Where's that described?
- ./api/keyupdater/authorisedkeys.go AuthorisedKeys(),
WatchAuthorisedKeys() expects exactly one authorized key, this seems
fragile
- Is -static-libgo still being used?
- Perhaps redundant to say it, the embedded code copies mostly need to be
packaged separately. I don't know to what extent they deserve review,
but they do represent a significant amount of code not written here that
will run as root in many environments.
There's a lot to like about the Juju codebase; error checking is rigorous,
the coding style is consistent, the shellscript quoting infrastructure is
awesome, it's inspired clever new Go packages that cleanly solve problems.
I didn't review as much as I would have liked, but what I did see looked
like rigorous work.
Juju has been growing new features at an incredible pace. Will development
of new features impede supporting deployed environments? The security
team cannot support Juju alone -- there is far too much domain-specific
knowledge required to properly maintain Juju. We will need the Juju
team's help to address practically every issue for all stages of future
security-relevant bugs: proper diagnosis, proper fix preperation,
proper backporting to all supported releases, proper test development,
and proper testing.
I'm concerned with how previous issues have been handled -- the three
referenced bug reports have combined to represent the single most
expensive consequence I've personally seen and all were known issues five
months earlier. So I need reassurance that the Juju team will help the
security team maintain Juju in our supported releases:
- Ask for an MRE, if that's the most appropriate mechanism to update Juju.
- Ask for special treatment that allow more frequent full-version updates,
if that's the most appropriate mechanism to update Juju.
- Commitment to help the security team diagnose and prepare fixes.
- Commitment to help the security team backport fixes to all supported
versions, as necessary.
- Commitment to help the security team prepare test cases and use testing
infrastructures.
This may represent enough work that dedicated Juju headcount may
eventually be necessary. LTS releases every two years and enthusiast
releases every six months add up quickly.
Thanks
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gccgo-5 in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR] juju-core, juju-mongodb, gccgo, golang
Status in gccgo-5 package in Ubuntu:
Fix Released
Status in gccgo-go package in Ubuntu:
Invalid
Status in golang package in Ubuntu:
Incomplete
Status in juju-core package in Ubuntu:
Confirmed
Status in juju-mongodb package in Ubuntu:
Incomplete
Bug description:
>> golang <<
Availability
------------
In universe, limited to amd64, i386 and armhf archs.
Rationale
---------
golang is the primary focus of Go toolchain development; scale testing
of juju with gccgo and golang gc built binaries revealed that the
gccgo built binaries consume a significant amount of memory compared
to golang gc built versions.
As juju is focussed on building scale out service deployments,
choosing the toolchain that produces the most scalable binaries on the
architectures that most users are going to be using would make sense.
Security
--------
Can't find any interesting security history.
QA
--
OK; the toolchain does have a test suite but its not run by default
(yet).
Dependencies
------------
All build-deps are in main; some non-core packages depend on package
in universe (kate, vim addons) - recommend that these are left in
universe.
golang-go.tools can be demoted to a suggested to limit scope of main
inclusion.
Standards compliance
--------------------
OK
Maintenance
-----------
>> gccgo-go <<
Availability
------------
In universe, available on all required architectures (x86, armhf,
arm64, ppc64el).
Rationale
---------
'go' build tool built using gccgo, avoiding the need to promote two
golang toolchains to Ubuntu main.
Security
--------
Searching for golang CVE's turned up nothing (this package is a rename
of the golang 1.2 source package).
Quality assurance
-----------------
Package installs cleanly, go tool installed using alternatives at
higher priority that golang-go version in universe.
Dependencies
------------
gccgo is in universe, all other dependencies in main.
Standards compliance
--------------------
OK
Maintenance
-----------
Some bugs expected upfront but should stabilize before release.
Probably picked up by ubuntu-server if foundations team don't want to.
Background information
----------------------
This package is a re-cut of the golang upstream codebase with selected
cherry-picks from upstream VCS for gccgo support, along with a patch
to support building using gccgo + Make.
The only code actually used is in src/cmd/go.
>> juju-mongodb <<
Availability
------------
In universe, available on all required architectures (x86, armhf,
arm64, ppc64el).
Rationale
---------
MongoDB is a dependency for operating a Juju deployed Ubuntu
environment.
Security
--------
MongoDB has had some CVE's in the past, related to the use of the V8
and Spidermonkey Javascript engine in the Mongo Shell; however juju-
mongodb builds without support for Javascript scripting, avoiding the
historic CVE's (which where fixed upstream anyway).
Quality assurance
-----------------
Package installs cleanly, package build process runs upstream smoke
tests (minus jstests due to disabling javascript support). Tests
pass on all architectures.
Dependencies
------------
All in main already
Standards compliance
--------------------
OK (well is scons but we won't hold that against it)
Maintenance
-----------
Upstream MongoDB run stable releases with point updates; its intended
that a MRE is applied for this package so point releases can be pushed
as SRU's.
Its also possible that we might need to bump a major version (2.4.x ->
2.6.x); as this package is specific to Juju, we can constrain the
impact and regression testing to Juju only.
Background information
----------------------
Why a separate package? it was agreed at the last vUDS that having a
separate package allows us to limit a) use of v8 (disabled) which was
a security concern and b) allows us to potentially update at a later
date if need be only impacting juju itself.
>> juju-core <<
Availability
------------
In universe.
Rationale
---------
Juju is the recommended service orchestration tool for Ubuntu; as such
it really needs to be a core part of Ubuntu.
Security
--------
No security history, but it was agreed that a security review would be
undertaken as part of the MIR process.
Quality assurance
-----------------
No tests are run as part of the package build process; however
upstream do run these tests for all target series (12.04 -> 14.04)
prior to release so the overall quality of the codebase it pretty
good.
The package has some basic DEP-8 tests that bootstrap a local Juju
environment to ensure everything hangs together OK.
Dependencies
------------
juju-mongodb (see above)
gccgo + gccgo-go
Currently all required go dependencies are snapshotted at specific
upstream commits and bundled with Juju.
Standards compliance
--------------------
OK
Maintenance
-----------
Upstream Juju team intend to manage stable point releases against the
version shipped in 14.04. Ubuntu Server team will own the package in
distro.
Background information
----------------------
Some decisions still need to be made, mainly around toolchain.
Specifically the aim is to support a single Go toolchain in Ubuntu
main for all architectures; golang-go does not support arm64 or
ppc64el yet, whereas the gccgo implementation does.
Required changes to support gccgo have been upstreamed into the Juju
codebase.
Its also worth noting that the package and binaries in Ubuntu are used
for:
client tool (juju)
juju agent (jujud) - but only for local provider and where --upload-tools is used
Upstream released jujud binaries are/will be distributed officially
via simplestreams using a documented build process (details TBC). The
juju client will use these tools on public clouds and potentially in
private cloud deployments where tools are synced into the cloud using
the juju client tool (juju sync-tools).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1267393/+subscriptions
More information about the foundations-bugs
mailing list