[Bug 1839271] Re: [MIR] zsys
$ ./change-override -c main -S zsys Override component to main zsys 0.3.3 in focal: universe/admin -> main zsys 0.3.3 in focal amd64: universe/admin/optional/100% -> main zsys 0.3.3 in focal arm64: universe/admin/optional/100% -> main zsys 0.3.3 in focal armhf: universe/admin/optional/100% -> main zsys 0.3.3 in focal ppc64el: universe/admin/optional/100% -> main Override [y|N]? y 5 publications overridden. ** Changed in: zsys (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
** Changed in: zsys (Ubuntu) Status: New => Confirmed ** Changed in: zsys (Ubuntu) Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
I reviewed zsys 0.3.3 as checked into focal. This shouldn't be considered a full audit but rather a quick gauge of maintainability. Unfortunately, the Ubuntu Security Team's tools are not well-developed when it comes to auditing golang projects, complicating the audit. zsys is a tool enhancing ZFS on linux, making it possible to run multiple ZFS setups on the same host. It has a client/server architecture, using grpc/protobuf over a unix domain socket to communicate. Policykit is used to mediate access to the server functions. - No CVE History - Build-Depends: golang, zfs, grub, and dbus - No pre/post inst/rm scripts. - There are three systemd units: - zsys-commit: for marking zsys boot as successful - zsysd.socket/zsysd.service: service to start/run zsysd - No dbus services - No setuid binaries - binaries in PATH? - zsysctl, zsysd - No sudo fragments - No udev rules - Polkit rules: - requires admin privs for most operations, user level stuff and querying does not - Has a good amount of unit tests, autopkgtests - No cron jobs. - No warnings/errors in buildlog - Most processes spawned are during build time; run time uses are to run update-grub, and via vendored dbus code (used by the polkit bits) to start a dbus session bus. Go intentionally does not invoke system shells to interpret commands. - Limited File IO, appears to be safe. - Logging is okay. - Environment variable use is okay. - Use of privileged functions? - Only Use of cryptography / random number sources appears to be sha1 for use in polkit/dbus communication. - Safe Use of temp files. - Networking code is okay. - zsysd uses polkit to authenticate clients communicating with the daemon. Use looks okay. Additionally, the gosec tool (https://github.com/securego/gosec) was used to look for issues. It found nothing of significance for zsys itself (a few unhandled errors). For the vendored code, the vast majority of things it found were unsafe.* calls that ought to be audited, and unhandled errors. While the zsys implementation is reasonably sized, there is unfortunately a fair amount of vendored code in the tree, including subsets of dbus and systemd modules. Security team ACK for promoting zsys to main. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
Now that the 0.3 series is published, it has the finale structure: - split between daemon and server. Calls are done via GRPC over an Unix socket. - use polkit for authorization with various levels of actions. Full spec is at https://docs.google.com/document/d/1oV5-ef-fqzML4MGd2LAHRcLdR0USKkOmrJW-AP0CmC4/edit#heading=h.dsunaoafgyat (page 23/24/25). We use SO_PEERCRED on the unix socket to get uid and pid of caller. All this is covered by tests. - man page autogenerated and updated when updating the pacakge - advanced shell completion (meaning: autogenerated, even complete hidden commands subcommands once fully typed) - updated README on the upstream project - i18n support. On the vendoring question, note that with go 1.13, we can know which are the real dependencies for the binary (exact commit): $ go version -m zsysd ... dep github.com/bicomsystems/go-libzfs v0.2.2-0.20190807094932-e50663fa5901 h1:+aBHo0MRYykwJKlV35t/PpU+P4LAgxaAUQKKWueHWlg= dep github.com/coreos/go-systemd v0.0.0-20190719114852-fd7a80b32e1f h1:JOrtw2xFKzlg+cbHpyrpLDmnN1HqhBfnX7WDiW7eG2c= dep github.com/godbus/dbus/v5 v5.0.3 h1:ZqHaoEF7TBzh4jzPmqVhE/5A1z9of6orkAe5uHoAeME= dep github.com/golang/protobuf v1.3.2 h1:6nsPYzhq5kReh6QImI3k5qWzO4PEbvbIW2cwSfR/6xs= dep github.com/k0kubun/pp v3.0.1+incompatible h1:3tqvf7QgUnZ5tXO6pNAZlrvHgl6DvifjDrd9g2S9Z40= dep github.com/mattn/go-colorable v0.1.2 h1:/bC9yWikZXAL9uJdulbSfyVNIR3n3trXl+v8+1sx8mU= dep github.com/mattn/go-isatty v0.0.8 h1:HLtExJ+uU2HOZ+wI0Tt5DtUDrx8yhUqDcp7fYERX4CE= dep github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4= dep github.com/snapcore/go-gettext v0.0.0-20190812090936-a77afd68d2bd h1:U17xEhsgCRqPKZAad3eyuHIb6zEkhCBf1auyeCgzWHM= dep github.com/spf13/cobra v0.0.5 h1:f0B+LkLX6DtmRH1isoNA9VTtNUK9K8xYd28JNNfOv/s= dep github.com/spf13/pflag v1.0.3 h1:zPAT6CGy6wXeQ7NtTnaTerfKOsV6V6F8agHXFiazDkg= dep golang.org/x/netv0.0.0-20191002035440-2ec189313ef0 h1:2mqDk8w/o6UmeUCu5Qiq2y7iMf6anbx+YA8d1JFoFrs= dep golang.org/x/sysv0.0.0-20191002091554-b397fe3ad8ed h1:5TJcLJn2a55mJjzYk0yOoqN8X1OdvBDUnaZaKKyQtkY= dep golang.org/x/text v0.3.2 h1:tW2bmiBqwgJj/UpqtC8EpXEZVYOwU0yG4iWbprSVAcs= dep google.golang.org/genproto v0.0.0-20191002211648-c459b9ce5143 h1:tikhlQEJeezbnu0Zcblj7g5vm/L7xt6g1vnfq8mRCS4= dep google.golang.org/grpc v1.24.0 h1:vb/1TCsVn3DcJlQ0Gs1yB1pKI6Do2/QNwxdKqmc/b0s= So, while the debian packaging system will make us MIR more than 60 packages (due to dependencies of dependencies, even if not used in finale binary), the real binary only use 16 of them (quite well known and maintained). We require specific version of them due to bug fixes, like dbus v5, go-libzfs specific commit, and so on. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
Hello Didier, I agree with you about the snapd, juju, ubuntu-report (first I've heard of this one), not de-vendoring their code. I understand they were given some exemptions because they wanted identical code across all the supported distributions they use. However, other distributions also want to reduce the amount of vendored code in their packages. (It's not just us that are finding Go an uneasy fit into our support model.) I'm also very concerned about dependencies breaking APIs regularly. This is tolerable over nine months but is painful over five or ten years. I realize that authors are being asked to bear the brunt of the cost of de-vendoring but will see limited benefits over the next ten years. The security team will see great benefits over the next ten years but does not pay the upfront cost. I don't have perfect solutions to this. I do believe that there are long term benefits to everyone for devendoring Go: - We can focus on providing stable APIs (and hopefully, eventually, ABIs, to eliminate rebuilding) - We can focus on providing security fixes across multiple concurrently supported versions rather than trying to support whatever was in git on a random date - There's less need to copy-and-paste security fixes and bug fixes and features - Because each project would standardize on a given version in a series, there's less backporting when fixes are needed: rather than having eg four versions in a series, for six series, there's just six versions, one per series - The autopackage tests from every project will probably have better code coverage, branch coverage, etc, of dependencies than any one project could (This isn't restricted to just Go and Rust of course: a recent CVE in C code affects 19 source packages because of vendoring. It realistically should have affected just two. While an aberration in our C packages, this is standard operating procedure with Go.) I firmly believe that devendoring is a crucial part of keeping our technical debt reasonable. Putting in the work to reduce code duplication up front will pay dividends over time that benefit everybody. You're right that the benefits also accrue more quickly when everyone participates. Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
Hey Seth, While I agree with this goal, I don't feel this is realistic without a focused effort within the distro itself as a global goal as I explained in detailed in my answer: - most of those deps are shared between snapd, juju, ubuntu-report and zsys at least (like the yaml config parser). All of them are using vendoring. I don't feel we should only have the new entree separately or the other will never be ported, and so, we will have no gain doing that work. - I don't feel it's fair and realistic to have zsys doing this work alone for the eoan time-goal while it was ok for the others to skip this process. (Hence the "should that be a goal for the LTS?"). Note that between direct and transitive deps, we have 31 packages to MIR. - As stated before, even if zsys we were doing that work for zsys, MIRing all dependencies, we are not sure that other projects like snapd could transition. Indeed, most of those modules are version 0.x, and they are breaking their API quite regularly. So the version zsys is compatible with wouldn't be the version snapd, or juju, or ubuntu-report will be compatible with. Is there a way to set that to a particular release goal and answer all the above? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
Indeed, we have asked for Go packages to have their vendored code split out into their own packages to simplify triage, fixing, and minimize rebuilding: https://wiki.ubuntu.com/MIRTeam#Embedded_sources_and_static_linking We'd like the package to build using golang -dev packages and not build the vendored code. There's no need to repack the orig tarball and no need to switch to dynamic linking. (The golang -dev packages allow us to track when packages need rebuilding through the Built-Using mechanism.) Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
After discussion int he MIR team we agreed on a +1 despite being a rather early 0.1 version for: - already implemented quite some of our requests - upstream == canonical on this project - more ideas for isolation are noted and on the todo list All of this is under the constraint that security is ok, as the biggest blockers are e.g. the vendored go libs. Ack for MIR Team Assingning to security ** Changed in: zsys (Ubuntu) Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
We discussed way more on IRC, thanks didrocks! I think we are safer now and low-hanging-fruit fixes are in. We are ready for a group-decision on allowing it for now given its somewhat special nature. didrocks will bring it up in the IRC meeting -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
- ack on weeport for haing internationalization in mind - https://github.com/ubuntu/zsys/commit/1bec99f4aa6a84c61f30cf12c83515d40ae578db looks good for some base extra isolation - thanks P.S. didn't see some of the content inline due to length limits - thanks for making me aware. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1839271] Re: [MIR] zsys
ok on the Lintian warning since you are ok in a pedanic check on Eoan. Mine was Bionic. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1839271] Re: [MIR] zsys
> > - I know it makes no sense in a container, but fix it so that it properly > > installs by changing default config/postinst or whatever you see fit > > See below, I need an example/more details of what is actually expected. > example: $ apt install zsys do that in a container and it is not allowed to fo RC!=0. The way you do it depends on your case (conditions in .service and such) > > - add watch file to your github > > Done in master > (https://github.com/ubuntu/zsys/commit/c390e46aa951c71b4154d769497a4a47e44aaae9). > However this triggers a lintian warning: W: zsys source: debian-watch- > file-in-native-package and I don't really like keeping lintian warnings. > > > - please resolve the lintian copyright complains > > Need feedback from you. What do you need? > > - extend autopkgtests to cover some real use-cases > > This is planned but not real for targetting eoan TBH. As you saw, we have a > very extensive testsuite (similary to ubuntu-report) and are really hard on > testing (running as part of building the package, but also in term of > upstream CI). > However, running on a real zfs-on-root system in autopkgtests is quite hard > to setup right now. This is why before zsys go "production ready", we really > need this (so that I can sleep at night ;)), knowing though that it needs a > lot of fundamental work to be setup on autopkgtests system. We already have > some autopkgtests to ensure we are compatible with our libzfs shipped by > ubuntu and that new zfs or grub doesn't regress us. But here, it means > installing a real entire system, with zfs on root (so debootstrapping or > copying current system, creating and accessing disks…), changing grub boot > menu entry for next reboot and cross-reboot tests (I worked with pitti in the > past to do this last item already for systemd autopkgtests, so it's not the > most worrying part compared to initial setup). This is logged as > https://github.com/orgs/ubuntu/projects/1#card-24794108. In a nutshell, I'm > afraid that's not a realistic target for eoan (and part of the reason we keep > it under the "experimental" flag). ok, but don't loose/punt the task after things got promoted :-) > > > - this seems to be at a very early stage, every here and there more features > are mentioned but not yet implemented. To review this it should sort of > feature complete at least to the extend that are planned for the comi,ng > release. Otherwise reviews cover what is there in 0.1 but e.g. 1.0 will > look much much different (If the feature is too far out at least add the > docs and specs to check if the design fits main inclusion) > > Indeed. We had a plan that you can see on > https://github.com/orgs/ubuntu/projects/1. However, we didn't get the time > resources (even less than half of what expected) we budgeted on at the start > of the cycle due to other customer work which got high priority. We thus > reduced to a MVP allowing people installing a zfs system on root, with > separated boot partition, enabling multiple (manual) snapshots for > rollbacking system AND/OR user data attached to it. This experimental option > will already help us a lot in term of exploring, testing and hardening zfs as > a viable root option before turning it to stable. > The most complex logic (grub + zsys boot) is now implemented. This > fundamental work is the most complex as it means datasets managements, > grouping them logically in different machines,- cloning system when booting > on snapshot, handling parallel installations, handling partial "system only" > revert. > The internal API for interacting with ZFS itself is already there and tested, > even if not used (destroy, snapshot and other tagging…). It means that future > improvement will be: > - implementing CLI options to expose/list what is already available on the > backend (installed machines, available snapshots, takes a snapshot and more). > However no "background work" should be needed and thus, this is just > "cosmetic" features if you prefer. > - implementing a GUI, which will use the exact same API than the CLI. > - doing some background automated snapshots, which is just going to be a > systemd unit triggering the same user command than manual snapshots. Tweaking > those will be done via systemd timer units. > - separate (which is already separated in code: internal/ vs cmd/) CLI and > backend, so that we have an on-demand zsys single daemon (avoiding having > multiple parallel commands starting in parallel for integrity, a single > daemon will know the state of the system and interact with it). This > client/server local communication will mean that we need some polkit > integration. This is the most invasive change in design between now and 1.0 > that we have and this means that we, as the Desktop team, will request later > on a security review again to ensure we did make it right security-wise. Yeah I think this is a special case, due to its timing cons
[Bug 1839271] Re: [MIR] zsys
Thanks for the review Christian! Sorry for the delayed answer, I'm just back from holidays :) Thanks also for the details and summary. I think I have some resolved, some questions and some with no actions. I copy this back here so that we can track them. Let me know how this feels. [Summary] > - go issue of embedded libs, can we resolve reduce this? I think there is no action needed here. Look at the details below for a (long) explanation. > - I know it makes no sense in a container, but fix it so that it properly > installs by changing default config/postinst or whatever you see fit See below, I need an example/more details of what is actually expected. > - add watch file to your github Done in master (https://github.com/ubuntu/zsys/commit/c390e46aa951c71b4154d769497a4a47e44aaae9). However this triggers a lintian warning: W: zsys source: debian-watch- file-in-native-package and I don't really like keeping lintian warnings. > - please resolve the lintian copyright complains Need feedback from you. > - needs a security review Pending > - enable more isolation features for for zsys-commit.service please Done, see below if this is good for you. > - add some documentation I guess not needed for eoan as there is nothing user visible (see more details below) > - extend autopkgtests to cover some real use-cases This is planned but not real for targetting eoan TBH. As you saw, we have a very extensive testsuite (similary to ubuntu-report) and are really hard on testing (running as part of building the package, but also in term of upstream CI). However, running on a real zfs-on-root system in autopkgtests is quite hard to setup right now. This is why before zsys go "production ready", we really need this (so that I can sleep at night ;)), knowing though that it needs a lot of fundamental work to be setup on autopkgtests system. We already have some autopkgtests to ensure we are compatible with our libzfs shipped by ubuntu and that new zfs or grub doesn't regress us. But here, it means installing a real entire system, with zfs on root (so debootstrapping or copying current system, creating and accessing disks…), changing grub boot menu entry for next reboot and cross-reboot tests (I worked with pitti in the past to do this last item already for systemd autopkgtests, so it's not the most worrying part compared to initial setup). This is logged as https://github.com/orgs/ubuntu/projects/1#card-24794108. In a nutshell, I'm afraid that's not a realistic target for eoan (and part of the reason we keep it under the "experimental" flag). > - this seems to be at a very early stage, every here and there more features are mentioned but not yet implemented. To review this it should sort of feature complete at least to the extend that are planned for the comi,ng release. Otherwise reviews cover what is there in 0.1 but e.g. 1.0 will look much much different (If the feature is too far out at least add the docs and specs to check if the design fits main inclusion) Indeed. We had a plan that you can see on https://github.com/orgs/ubuntu/projects/1. However, we didn't get the time resources (even less than half of what expected) we budgeted on at the start of the cycle due to other customer work which got high priority. We thus reduced to a MVP allowing people installing a zfs system on root, with separated boot partition, enabling multiple (manual) snapshots for rollbacking system AND/OR user data attached to it. This experimental option will already help us a lot in term of exploring, testing and hardening zfs as a viable root option before turning it to stable. The most complex logic (grub + zsys boot) is now implemented. This fundamental work is the most complex as it means datasets managements, grouping them logically in different machines,- cloning system when booting on snapshot, handling parallel installations, handling partial "system only" revert. The internal API for interacting with ZFS itself is already there and tested, even if not used (destroy, snapshot and other tagging…). It means that future improvement will be: - implementing CLI options to expose/list what is already available on the backend (installed machines, available snapshots, takes a snapshot and more). However no "background work" should be needed and thus, this is just "cosmetic" features if you prefer. - implementing a GUI, which will use the exact same API than the CLI. - doing some background automated snapshots, which is just going to be a systemd unit triggering the same user command than manual snapshots. Tweaking those will be done via systemd timer units. - separate (which is already separated in code: internal/ vs cmd/) CLI and backend, so that we have an on-demand zsys single daemon (avoiding having multiple parallel commands starting in parallel for integrity, a single daemon will know the state of the system and interact with it). This client/server local communication
[Bug 1839271] Re: [MIR] zsys
[Summary] It generally looks good already for being at such an early stage, the following list covers what I think need to be added/improved to make it acceptable. - go issue of embedded libs, can we resolve reduce this? Please answer my questions below. - I know it makes no sense in a container, but fix it so that it properly installs by changing default config/postinst or whatever you see fit - add watch file to your github - please resolve the lintian copyright complains - needs a security review - enable more isolation features for for zsys-commit.service please - add some documentation - extend autopkgtests to cover some real use-cases - this seems to be at a very early stage, every here and there more features are mentioned but not yet implemented. To review this it should sort of feature complete at least to the extend that are planned for the coming release. Otherwise reviews cover what is there in 0.1 but e.g. 1.0 will look much much different (If the feature is too far out at least add the docs and specs to check if the design fits main inclusion) [Duplication] There is no other tool doing that job. [Embedded sources and static linking] No static (C) linking, but this is golang and uses the classic approach of bundling a lot of vendor libs. Of your bundled libs I found almost all in the archive (package names): golang-gopkg-yaml.v2-dev golang-golang-x-xerrors-dev golang-golang-x-sys-dev golang-github-spf13-cobra-dev golang-github-spf13-pflag-dev golang-github-sirupsen-logrus-dev golang-github-mattn-go-colorable-dev golang-github-mattn-go-isatty-dev golang-github-konsorten-go-windows-terminal-sequences-dev golang-github-k0kubun-pp-dev golang-github-inconshreveable-mousetrap-dev golang-github-google-go-cmp-dev The only one I didn't find was vendor/github.com/bicomsystems/go-libzfs/ Of course this would also mean you'd have to MIR all of those as well. But that is what the code review here has to do. So the amount of code to be verified/reviewed/maintained would not change And otherwise things have to maintained multiple times. I know ABI instabilities are an issue, but you'd know which release you target. Or are you planning to maintain one version of zsys for all future Ubuntu releases? In that case I see why you bundle the versions, but be aware of the tracking and updating that you'll have to do for all of them. Same for the security team, they need to track all those components for potentially many Go packages. Currently the rule to keep them bundled is: "the requesting team must state their commitment to testing no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release." Hence I'd like the Desktop and the Security Team state here on the bug that a) they are aware b) they are willing and able to do that tracking and updating [Security] OK: - history of CVEs I have not found any known CVEs. But zsys obviously is brand new and the golang components are very hard to search/track. So I think it is ok from the "known CVEs" - no use of webkit, lib*v8 - does not process arbitrary web content - does not manage centralized online accounts - does not integrates arbitrary javascript into the desktop - does not deal with system authentication - does not open a port (at least I think so) - runs a daemon as root - sort of ok Just the one that commits the passed boot, but could we throw that one into all sorts of privTMP/priv*** and other systemd restrictions? Security sensitive for: - parsing data formats (on disk) IMHO this is security sensitive as it needs to get access (and can prevent) to most of the disk data. If exploited it could pass data on. Therefore I request a security review of this as well. [Common blockers] OK: - no FTBFS currently? - build time internal tests seem excessive thanks for those - desktop-packages is already subscribed - no python package, so no extra python
