[00:05] <pombreda> sbeattie: wrt. to the ubuntu security data license you wrote: "I'll poke people internally about getting more explicit statements in place." --> Thanks!
[00:13] <pombreda> sbeattie: the vast majority of vulnerability feeds are using some custom permissive license (like the NVD and Mitre) or CC-BY (permissive) or CC-BY-SA (weak copyleft) licenses. The aggregated combined data in vulnerablecode is therefore CC-BY-SA which is the highest common denominator. It would be nice to have one of these licenses. I am somewhat puzzled that in many cases we seem to be the first ones to inquire about the 
[00:13] <pombreda> license of these feeds :)
[00:15] <pombreda> Many are proprietary such as https://github.com/pyupio/safety-db or Snyk, OSSindex and more... we are trying to offer an open alternative to these. 
[01:59] <JanC> I wonder if for "factual data" like that there aren't more appropriate licenses that allow use, aggregation, etc. but don't allow changes
[02:40] <tomreyn> is multiverse supposed to be enabled by defualt on new desktop and server installs?
[02:40] <tomreyn> 20.04 + 22.04
[02:46] <sdeziel> tomreyn: AFAIK, it is, yes
[02:46] <tomreyn> "bm" in #ubuntu points to https://bugs.launchpad.net/ubuntu/+source/unrar-nonfree/+bug/1975722 + https://ubuntu.com/security/CVE-2022-30333 - i pointed them to https://wiki.ubuntu.com/SecurityTeam/FAQ and the (non) supported repositories statement. but with multiverse enabled by default, users not aware of what received (guaranteed) security support have a good chance of running into surprises
[02:46] -ubottu:#ubuntu-security- Launchpad bug 1975722 in unrar-nonfree (Ubuntu) "unrar has an open security bug" [Undecided, Confirmed]
[02:46] -ubottu:#ubuntu-security- RARLAB UnRAR before 6.12 on Linux and UNIX allows directory traversal to write to files during an extract (aka unpack) operation, as demonstrated by creating a ~/.ssh/authorized_keys file. NOTE: WinRAR and Android RAR are unaffected. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30333>
[02:55] <sdeziel> tomreyn: same goes with universe though
[02:55] <sdeziel> hmm, Ubuntu Pro changes things a bit for universe
[02:57] <tomreyn> not for free riders, although expectations, maybe
[02:58] <tomreyn> or assumptions
[03:07] <tomreyn> My POV is that making software which receives no (or no timely) security updates available by default on servers and desktop makes it too easy for users to make critical mistakes. i'd expect having to tick a box or edit a configuration file (such as uncommenting the universe + multiverse line in sources.list, where it should be (and i think is) stated that those recieve no security support) to indicate that the user is willing to accept 
[03:07] <tomreyn> the risk.
[03:09] <tomreyn> i assume that the current situation is the outcome of a change that was discussed at some time (probably years ago), though, and was a well evaluated choice.
[03:10] <tomreyn> nowadays you could possibly argue that snaps are also always easily available and not necessarily getting security support, nor even hint on their support status.
[03:10] <tomreyn> s/status/policy/
[03:12] <tomreyn> i have a feeling (but definitely not proof) that multiverse was not enabled by default on earlier releases
[03:20] <tomreyn> looks like my memory is failing me. apparently, while there were some hickups during 18.04 / subiquity / "alternative installer" (d-i) times, universe  + multiverse have been enabled for a long time on servers, too https://askubuntu.com/questions/1081243/why-do-i-need-to-enable-universe-repo-in-18-04-isnt-it-default-enabled
[03:23] <tomreyn> still, the point about "unexpected/non-accepted risk" remains from my POV. sorry for the long discussion.