Re: [gentoo-dev] zoom concerns
On Thu, 2020-04-02 at 10:13 +0800, William Kenworthy wrote: > And I would like to add that sometimes you don't have a choice - if > someone who is paying you says to use zoom, there is no choice You always have a choice. You can live poor and happy! ;-) > - but I > would rather use gentoo than fire up the MS laptop.. ...and here's where we disagree. It's better to run risky apps on a throwaway system than let them damage or crack your primary system. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] zoom concerns
And I would like to add that sometimes you don't have a choice - if someone who is paying you says to use zoom, there is no choice - but I would rather use gentoo than fire up the MS laptop.. What gentoo can do is mitigate the risk - which I need to look into to see whats done in the ebuild over a default install of their binary.. William K. On 2/4/20 8:53 am, Alec Warner wrote: On Wed, Apr 1, 2020 at 5:18 PM Alessandro Barbieri mailto:lssndrbarbi...@gmail.com>> wrote: I have concerns about the inclusion of zoom in ::gentoo. For me it's more like a malware. From the hacker news feed you'll find out that: [1] zero day vulnerability found [2] passwords are truncated to 32 bit [3] previously sent data to facebook [4] end to end traffic isn't encrypted [5] signed binary run unsigned script [1], [2], [5] all seem like bugs and I'd expect upstream to fix at least [1] and [5]. Note that in Gentoo [3] isn't directly relevant (this isn't iOS) and neither is [5] in most cases as people don't run signed binaries or use any kind of binary whitelisting in Gentoo. [2] I think the article mentions the truncation is to 32 bytes (or '32 chars', but I assume each char is 1 byte for entropy sake.); not 32 bits. Most password fields have a length limit (you cannot accept arbitrary long passwords. If 32 characters isn't enough length to protect users then the passwords are going to be useless anyway; most user passwords are significantly less than 32 characters. This is significantly different than limited to '32 bits' (which is 4 characters!) and would make brute forcing passwords an obvious breeze; there is not sufficient entropy in 32 bits to protect users. [4] I agree the poor marketing is a problem. I think as Rich states later in the thread it's possible we could provide more information here. As he notes though, I'm not convinced this is reason not to package the software in Gentoo from a policy perspective. In general I expect that as long as Zoom has a gentoo maintainer and upstream actually resolves outstanding security issues; I'm not really aware of any policy hurdles they need to overcome to stay packaged in Gentoo. Currently it has three maintainers[6]. If it sucks, convince them to stop maintaining it ;) -A 1 https://techcrunch.com/2020/04/01/zoom-doom/?guccounter=1 2 https://news.ycombinator.com/item?id=22749706 3 https://www.vice.com/en_us/article/z3b745/zoom-removes-code-that-sends-data-to-facebook 4 https://theintercept.com/2020/03/31/zoom-meeting-encryption/ 5 https://news.ycombinator.com/item?id=22746764 [6] https://packages.gentoo.org/packages/net-im/zoom
Re: [gentoo-dev] zoom concerns
On Wed, Apr 1, 2020 at 5:18 PM Alessandro Barbieri wrote: > I have concerns about the inclusion of zoom in ::gentoo. For me it's more > like a malware. > From the hacker news feed you'll find out that: > > [1] zero day vulnerability found > [2] passwords are truncated to 32 bit > [3] previously sent data to facebook > [4] end to end traffic isn't encrypted > [5] signed binary run unsigned script > > [1], [2], [5] all seem like bugs and I'd expect upstream to fix at least [1] and [5]. Note that in Gentoo [3] isn't directly relevant (this isn't iOS) and neither is [5] in most cases as people don't run signed binaries or use any kind of binary whitelisting in Gentoo. [2] I think the article mentions the truncation is to 32 bytes (or '32 chars', but I assume each char is 1 byte for entropy sake.); not 32 bits. Most password fields have a length limit (you cannot accept arbitrary long passwords. If 32 characters isn't enough length to protect users then the passwords are going to be useless anyway; most user passwords are significantly less than 32 characters. This is significantly different than limited to '32 bits' (which is 4 characters!) and would make brute forcing passwords an obvious breeze; there is not sufficient entropy in 32 bits to protect users. [4] I agree the poor marketing is a problem. I think as Rich states later in the thread it's possible we could provide more information here. As he notes though, I'm not convinced this is reason not to package the software in Gentoo from a policy perspective. In general I expect that as long as Zoom has a gentoo maintainer and upstream actually resolves outstanding security issues; I'm not really aware of any policy hurdles they need to overcome to stay packaged in Gentoo. Currently it has three maintainers[6]. If it sucks, convince them to stop maintaining it ;) -A > 1 https://techcrunch.com/2020/04/01/zoom-doom/?guccounter=1 > 2 https://news.ycombinator.com/item?id=22749706 > 3 > https://www.vice.com/en_us/article/z3b745/zoom-removes-code-that-sends-data-to-facebook > 4 https://theintercept.com/2020/03/31/zoom-meeting-encryption/ > 5 https://news.ycombinator.com/item?id=22746764 > [6] https://packages.gentoo.org/packages/net-im/zoom
Re: [gentoo-dev] zoom concerns
On Wed, Apr 1, 2020 at 8:18 PM Alessandro Barbieri wrote: > > I have concerns about the inclusion of zoom in ::gentoo. For me it's more > like a malware. > From the hacker news feed you'll find out that: I guess we could stick an einfo in the post-install messages, but if you're joining a zoom meeting are you going to be any more secure if you manually install the files instead? I can't imagine that people are going to stop attending meetings just because they picked the wrong software to host them. Plus a few of those concerns apply to MANY packages - such as a lack of end-to-end encryption, or ever having had a zero day. I'm not intending to endorse Zoom here, but Gentoo isn't really intended as a purist distro that will never include a package if it is associated with a service that might collect user data and so on. In fact, we have many packages with these associations. Ultimately users can decide what they want to run, and we're just providing the files in the most convenient and secure manner possible. For example, when the zero day is fixed if you're using Gentoo you'll benefit from our security policy, while you would not if you had just manually installed some files/etc... -- Rich
[gentoo-dev] Last-rites: sys-block/kvpm
# Andreas Sturmlechner (2020-04-02) # Broken and unmaintained upstream, last commit in 2016, bug #715594 # Use sys-block/partitionmanager instead. Masked for removal in 30 days. sys-block/kvpm
[gentoo-dev] zoom concerns
I have concerns about the inclusion of zoom in ::gentoo. For me it's more like a malware. >From the hacker news feed you'll find out that: [1] zero day vulnerability found [2] passwords are truncated to 32 bit [3] previously sent data to facebook [4] end to end traffic isn't encrypted [5] signed binary run unsigned script 1 https://techcrunch.com/2020/04/01/zoom-doom/?guccounter=1 2 https://news.ycombinator.com/item?id=22749706 3 https://www.vice.com/en_us/article/z3b745/zoom-removes-code-that-sends-data-to-facebook 4 https://theintercept.com/2020/03/31/zoom-meeting-encryption/ 5 https://news.ycombinator.com/item?id=22746764
Re: [gentoo-dev] network sandbox challenge
On Wed, Apr 01, 2020 at 11:30:00PM +0100, Samuel Bernardo wrote:
> Hi Robin,
>
> On 4/1/20 11:07 PM, Robin H. Johnson wrote:
> >>> # I am considering removing this and just hard coding mirror://goproxy
> >>> # below, so please do not rely on it.
> >>> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
> >> So, go-module.eclass provides a good base to follow SRP pattern (single
> >> responsibility principle). Looking into that effort I would copy
> >> go-module.eclass to my overlay eclass directory and adapt it to use my
> >> mirror type.
> >>
> >> I would like to use directly Gentoo maintained go-module.eclass, but for
> >> that I would like to have access to set my own mirror type.
> >>
> >> I also ask you to update documentation since there is some details to
> >> use EGO_SUM, such as you stated in comment[4].
> > It's not clear why you need to modify the mirror behavior at all; maybe
> > you covered that elsewhere in this overly long thread.
>
> Remembering that I'm in overlay context, lets consider the use case with
> a private repository with restricted access from where I need to get
> some go module. I need to use an alternative mirror not listed in
> default goproxy mirror type.
Ok, so what you're REALLY asking for here, is a cleaner way to specify
that a go module that exists OUTSIDE of the upstream Goproxy ecosystem.
The eclass as it stands was written as a way to CONSUME the upstream
Goproxy ecosystem efficiently, without producing a bundling mess.
This is not entirely a Gentoo packaging problem, but also intersects
upstream Go packaging, specifically that outside of the ebuild you have
to take special measures to cause 'go mod' to fetch from your
alternative mirror that contains private modules. Upstream also doesn't
have a good handle on how to solve this problem for ALL of the edge
cases (see GOPRIVATE and interactions with the GOSUMDB).
Your package that consumes that go module PROBABLY also consumes many
public go modules, so you don't want to modify or mirror every single
entry: just the private ones.
I propose the following rough improvement to the go-module.eclass for
EGO_SUM usage in the above case.
EGO_SUM=(
"github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
"github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
)
EGO_SUM_WITH_BASE=(
"mirror://private/ internal.com/foo/disco v1.2.3/go.mod"
"mirror://private/ internal.com/foo/disco v1.2.3"
"https://site2/ mycompany.com/bar/dance v2.3.4/go.mod"
"https://site2/ mycompany.com/bar/dance v2.3.4/"
)
EGO_SUM can be trivially transformed to EGO_SUM_WITH_BASE, by adding the
mirror://goproxy/ slug as a first argument.
The implementation of go-module_set_globals remains almost identical,
just using the new first argument rather than the
${_GOMODULE_GOPROXY_BASEURI} variable.
--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
[gentoo-dev] News item: Deprecation and removal of legacy X11 input drivers.
Title: Deprecation and removal of legacy X11 input drivers. Author: Piotr Karbowski Posted: 2020-04-02 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: x11-drivers/xf86-input-mouse Display-If-Installed: x11-drivers/xf86-input-keyboard The Gentoo X11 Team is announcing the deprecation and future removal of the legacy X11 input drivers x11-drivers/xf86-input-mouse and x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers will be masked for removal. These drivers have been deprecated for many years, first by xf86-input-evdev and then by xf86-input-libinput. The only use for those drivers remain in deployments which intentionally opt-out of using udev, as both evdev and libinput require udev during runtime, however given that upstream has already removed the Linux support from xf86-input-keyboard, future X11 releases will no longer support xf86-input-keyboard on Linux rendering those installation infeasible to use without udev. In order to ensure fraction-less upgrade path for future X11 releases, we have decided to deprecate those drivers that are not in active use by pretty much any installation of Gentoo. No action is required from end-users who are already using libinput (or evdev). To check which driver is in use, one can use $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log For the systems running xorg-server as regular user (-suid +elogind/+systemd) or by running # grep 'Using input driver' /var/log/Xorg.0.log for those that still runs xorg-server as root. If however neither libinput or evdev is in use, one should append 'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf and update @world with new USE flags # emerge -N @world signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] network sandbox challenge
On Wed, Apr 01, 2020 at 04:14:48PM -0400, Michael Orlitzky wrote: > On 4/1/20 4:03 PM, Samuel Bernardo wrote: > > > > Couldn't security issue in a Go library be solved with keyword mask and > > announce in portage? > > If there's an ebuild for the library, then yeah, you've got the right > idea. But with the Go eclasses, there are no ebuilds for any of the > dependencies. The problem goes deeper than that, and is more of an upstream concern than a Gentoo concern: because the Go module ecosystem pins exact versions, not version ranges, and this is a crucial part of reproducible builds. Let the library be "L", with versions 1,2. The vulnerable version is L-1, and L-2 contains the fix. Let the package that uses the library be "P", with version 1 only. If you wanted to USE L-2 in P-1, you generally must make modifications to the consumers of that library. At the very least you have to modify the go.mod file to use the new version. To satisfy the package checksums/security in the Go ecosystem, you ALSO need to update the go.sum file. If the vulnerable library is a transitive dependency (e.g. indirect via another library), then you ALSO need to update that other consumer. At the point that there IS a reliable way to get lists of vulnerable versions of Go modules, including the horrible timestamped v0.0.0 versions, the EGO_SUM work does contain enough data to identify ALL vulnerable outputs on your system. That listing isn't available yet, due to upstream working on it still: https://github.com/golang/go/issues/24031 That listing would be transformed into a GLSA input criterion, to identify vulnerable Gentoo packages (at which point upstream Golang has hopefully also provided a cleaner way to bump/patch the dependency in the scope of reproducible versions). -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] network sandbox challenge
Hi Robin,
On 4/1/20 11:07 PM, Robin H. Johnson wrote:
>>> # I am considering removing this and just hard coding mirror://goproxy
>>> # below, so please do not rely on it.
>>> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
>> So, go-module.eclass provides a good base to follow SRP pattern (single
>> responsibility principle). Looking into that effort I would copy
>> go-module.eclass to my overlay eclass directory and adapt it to use my
>> mirror type.
>>
>> I would like to use directly Gentoo maintained go-module.eclass, but for
>> that I would like to have access to set my own mirror type.
>>
>> I also ask you to update documentation since there is some details to
>> use EGO_SUM, such as you stated in comment[4].
> It's not clear why you need to modify the mirror behavior at all; maybe
> you covered that elsewhere in this overly long thread.
Remembering that I'm in overlay context, lets consider the use case with
a private repository with restricted access from where I need to get
some go module. I need to use an alternative mirror not listed in
default goproxy mirror type.
Ok, you can say that since is not public what is the point of creating
an ebuild? Well the ebuild (so easy to do) turns smooth the maintenance,
the installation into my environment, to reproduce it later to install
in real infrastructure and also provide me a tar.gz or rpm package using
the awesome power of Gentoo!
Btw, my workspace have two overlays for now:
- local private overlay
- public overlay (where I share what can be shared)
Thanks for your advices,
Samuel
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] network sandbox challenge
On Wed, Apr 01, 2020 at 12:50:56PM +0100, Samuel Bernardo wrote:
> Hi Robin,
>
> On 4/1/20 6:36 AM, Robin H. Johnson wrote:
> > Samuel:
> > I already proved that using go-module.eclass EGO_SUM it will NOT use Git
> > repositories, and all of the fetching will happen long before
> > src_unpack. Why do you persist with your statement to the contrary?
>
> Sorry my misunderstanding, but I didn't get it right with what you
> mentioned to me before:
>
> > Have you looked at the EGO_SUM in go-module? This already covers ANY go
> > package that uses go.mod + go.sum, in a fully reproducible way that does
> > not break network sandbox.
> I looked into the eclass documentation and I only found EGO_VENDOR[1].
> This seems so expensive since I need to parse all go.mod or go.sum files
> that I concluded would be better to use a tar.gz with all dependencies
> (remember that my use case is with my personal overlay).
Thanks, it seems the eclass HTML documentation is not updating
correctly (it's showing the content of the eclass-manpages-20200213
version right now, despite the "Updated: Apr 2020" text). I've pushed a
change and the corrected documentation is now visible.
Thank you for bringing this to our attention.
> Looking deeply into the source code I could find more details about
> EGO_SUM that only needs to set the urls to go.mod or/and go.sum files
> present in the repository. This is useful, but only to official gentoo
> developers, since if I want to use my own mirror type, for instance
> mirror://gooverlay, I wouldn't have that option[3]:
You don't need to override _GOMODULE_GOPROXY_BASEURI at all.
_GOMODULE_GOPROXY_BASEURI (with the default of mirror://goproxy/)
expands to the UPSTREAM locations that have the Go modules available.
It expects those mirrors to have the layout of files used by upstream.
> > # I am considering removing this and just hard coding mirror://goproxy
> > # below, so please do not rely on it.
> > : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
> So, go-module.eclass provides a good base to follow SRP pattern (single
> responsibility principle). Looking into that effort I would copy
> go-module.eclass to my overlay eclass directory and adapt it to use my
> mirror type.
>
> I would like to use directly Gentoo maintained go-module.eclass, but for
> that I would like to have access to set my own mirror type.
>
> I also ask you to update documentation since there is some details to
> use EGO_SUM, such as you stated in comment[4].
It's not clear why you need to modify the mirror behavior at all; maybe
you covered that elsewhere in this overly long thread.
--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
Re: [gentoo-dev] network sandbox challenge
On 4/1/20 4:03 PM, Samuel Bernardo wrote: > > Couldn't security issue in a Go library be solved with keyword mask and > announce in portage? If there's an ebuild for the library, then yeah, you've got the right idea. But with the Go eclasses, there are no ebuilds for any of the dependencies.
Re: [gentoo-dev] network sandbox challenge
Hi Michael, On 4/1/20 6:01 PM, Michael Orlitzky wrote: > On 4/1/20 11:49 AM, Alec Warner wrote: >> Imagine a common dep (CommonFoo-x-y-z) >> has a security problem, so we must upgrade to CommonFoo-y-z. In the >> scenario where CommonFoo is a dynamically linked package we can >> recompile it once[4] and new consumers will just use the new dynamic >> shared object. In a bundling scenario, we will be forced to rebuild[5] >> all consumers. > This is highly euphemistic. What actually happens is: someone discovers > a security issue in a Go library. That library is not "in" Gentoo, > because it only ever appears in a string inside of another ebuild that > bundles everything. Thereafter, a whole lot of nothing happens. Users > remain vulnerable "forever," until some other unrelated event causes > both the ebuild and its dependency to be updated. Couldn't security issue in a Go library be solved with keyword mask and announce in portage? The vulnerability care is not only related to the distro, but also to the upstream. Gentoo already provides the option to downgrade to a previous version (if that is an answer for the issue). Imagine Arch distro where that is not an option or Debian Stable that is stuck in a version? I see so more troubles in other distros than Gentoo. The choice is the responsibility of the end user and distro maintainers don't have to provide every software. Providing the eclasses that allows to produce the ebuild is a good option for those who need some software, simplifying the development work. Overlaying is the solution, I think... Best, Samuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: media-fonts/symbola
> "UM" == Ulrich Mueller writes: UM> So, removal of the package seems to be the only option that makes sense, UM> unless we would downgrade to that old version. Agreed. Cest la vie. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] network sandbox challenge
Hi Alec, Really great reading about packaging and the current challenges. This would be great to be posted in Gentoo blog! --- To all community: I would like to commend the know how of Gentoo community and their principles. I would like to evidence relatively to other distributions some points that IMHO turns Gentoo the greatest (win in all points): - QA - freedom - tooling - know how - velocity - security - slotting - learning - sharing - straightforwardness - objectivity - mirroring - package system - **extensibility** Overlays, ebuild and profile definitions in Gentoo extends the freedom of the ingenious distro ever made. There are no barriers, so please don't forget the overlays when developing Gentoo code base that would help everyone to extend their needs and follow the good QA practices. There is nothing like Gentoo! Thank you all that contribute to Gentoo! On 4/1/20 4:49 PM, Alec Warner wrote: > > On Wed, Apr 1, 2020 at 5:14 AM Samuel Bernardo > mailto:samuelbernardo.m...@gmail.com>> > wrote: > > Forgive my noobishness in this matter that let Alec to comment > over my own statement. > > Alec pointed out some very important issues in go development that > break copyright infringement and security vulnerabilities, but I'm > sure that is not related to the good work done in go-module.eclass > to surpass all go mess. npm is worst and I take from go-module as > a good pattern to apply also into there. > > I am antarus, not mjo (but more on that below!) I don't believe > bundling presents many challenges with regards to copyright > infringement. As a package maintainer you should know the licenses > used in your packages. You are required to reflect any licenses used > in the LICENSE ebuild variable. Obviously this becomes more work if > you are using a bundle due to the fact that bundling will include more > code. In the golang ecosystem there is a tool to help maintainers do > this (https://packages.gentoo.org/packages/dev-go/golicense). I get > that with bundling we cannot share the work from previous packages > because packages are not shared in a bundled environment but I expect > the golicense tool to have good coverage in practice. If the tool does > the work, sharing the work becomes moot. > > I think licensing can be more challenging in other bundling scenarios > where tooling is not provided; but note that this is not significantly > different from the unbundled scenario in terms of license discovery. > If I am packaging a new program (A) and it depends on (B,C,D) I have > two options. I can either package [A,B,C,D] (normal gentoo way) or I > can package [A] (with B,C,D bundled). The intersection of the LICENSE > variables is the same effort for both here. The benefit of the > multiple packages is that future users of B,C,D can re-use the license > discovery work and that isn't nothing. > > Going back to my overlay use case, will go-modules download all > modules to distfiles directory? The naming convention will assure > that there will be no modules repetition? > > What about eclean-dist, will it work as expected for those modules > dependencies? > > I think some of this answers would worth mention in documentation. > > Sorry for anything I wrongly stated and thank you very much for > your help, > > Samuel > > I've chosen this part to write my treatise on packaging, but rest > assured it's mostly intended as a response to mgorny and mjo; not > specifically in response to you. > > The very long answer is that Gentoo was designed around a paradigm of > programs written primarily in C. In C programs you have the ability to > link to libraries which offer APIs and in the ideal case, each API is > offered via a unique SONAME[0]. Upstream packages were written and > built in this way (with dynamic linking). So in the case of package A, > that uses libraries B, C, and D; the result in many distributions is 4 > packages (A,B,C,D) and users who want A will get B, C, and D > installed. This in fact was a major selling point of package managers > at the time because finding these dependencies by hand and building > and merging them all was painful. > > Many applications break this trend; I don't think golang or nodejs are > particularly new (python and ruby have had (pip, venv) and rubygems[1] > for years, for example, which are similar bundling paradigms.) The > struggle as packagers and distribution managers is when upstream > decides "my software should be installed via a bundling solution > (golang, node, pip, rubygems, and so on)" we are left to decide both > whether to map this to the ebuild paradigm (no bundling of > dependencies) or omit ebuilds entirely. In the former case we are > often left working at odds with upstream (who are confused by our > decomposition of their application) and in the latter case, users > often use the bundle anyway (e.g. they install the packages by hand or > use the ruby gems or whatever.) I
Re: [gentoo-dev] network sandbox challenge
On 4/1/20 11:49 AM, Alec Warner wrote: > Imagine a common dep (CommonFoo-x-y-z) > has a security problem, so we must upgrade to CommonFoo-y-z. In the > scenario where CommonFoo is a dynamically linked package we can > recompile it once[4] and new consumers will just use the new dynamic > shared object. In a bundling scenario, we will be forced to rebuild[5] > all consumers. This is highly euphemistic. What actually happens is: someone discovers a security issue in a Go library. That library is not "in" Gentoo, because it only ever appears in a string inside of another ebuild that bundles everything. Thereafter, a whole lot of nothing happens. Users remain vulnerable "forever," until some other unrelated event causes both the ebuild and its dependency to be updated. Your license scenario is also wishful thinking. All of the LICENSE bugs reported when this eclass was proposed have been sitting open for six months. As soon as the eclass was committed, that shit went out the door and the developers moved on to make more money at our expense. You got scammed.
Re: [gentoo-dev] network sandbox challenge
On Wed, Apr 1, 2020 at 5:14 AM Samuel Bernardo < samuelbernardo.m...@gmail.com> wrote: > Hi Robin, > On 4/1/20 6:36 AM, Robin H. Johnson wrote: > > Normally we don't bundle dependencies, avoiding that problem entirely. > The Go eclasses however are badly designed, committed against protest by > paid corporate interests, and serve only to facilitate large-scale > copyright infringement and security vulnerabilities. If you're looking > for a consistent explanation of how they're supposed to work with the > rest of Gentoo, you won't find one. > > mjo: Can you please substantiate your claims? > > It would have been nice to have heard your concerns during February, any > of one the three times that William and I posted the go-module.eclass > EGO_SUM development work for review on this mailing list. I don't see a > single email from you during that entire period. > > The EGO_SUM support explicitly ensured that upstream distfiles (for each > dependency) remained absolutely as upstream provided them, without > merging the distfiles together or altering their content in way (I admit > that the exact naming of the distfiles changed, because it was terrible, > v0.0.0-20190311183353-d8887717615a.zip for example). > > Forgive my noobishness in this matter that let Alec to comment over my own > statement. > > Alec pointed out some very important issues in go development that break > copyright infringement and security vulnerabilities, but I'm sure that is > not related to the good work done in go-module.eclass to surpass all go > mess. npm is worst and I take from go-module as a good pattern to apply > also into there. > I am antarus, not mjo (but more on that below!) I don't believe bundling presents many challenges with regards to copyright infringement. As a package maintainer you should know the licenses used in your packages. You are required to reflect any licenses used in the LICENSE ebuild variable. Obviously this becomes more work if you are using a bundle due to the fact that bundling will include more code. In the golang ecosystem there is a tool to help maintainers do this ( https://packages.gentoo.org/packages/dev-go/golicense). I get that with bundling we cannot share the work from previous packages because packages are not shared in a bundled environment but I expect the golicense tool to have good coverage in practice. If the tool does the work, sharing the work becomes moot. I think licensing can be more challenging in other bundling scenarios where tooling is not provided; but note that this is not significantly different from the unbundled scenario in terms of license discovery. If I am packaging a new program (A) and it depends on (B,C,D) I have two options. I can either package [A,B,C,D] (normal gentoo way) or I can package [A] (with B,C,D bundled). The intersection of the LICENSE variables is the same effort for both here. The benefit of the multiple packages is that future users of B,C,D can re-use the license discovery work and that isn't nothing. > Going back to my overlay use case, will go-modules download all modules to > distfiles directory? The naming convention will assure that there will be > no modules repetition? > What about eclean-dist, will it work as expected for those modules > dependencies? > > I think some of this answers would worth mention in documentation. > > Sorry for anything I wrongly stated and thank you very much for your help, > > Samuel > I've chosen this part to write my treatise on packaging, but rest assured it's mostly intended as a response to mgorny and mjo; not specifically in response to you. The very long answer is that Gentoo was designed around a paradigm of programs written primarily in C. In C programs you have the ability to link to libraries which offer APIs and in the ideal case, each API is offered via a unique SONAME[0]. Upstream packages were written and built in this way (with dynamic linking). So in the case of package A, that uses libraries B, C, and D; the result in many distributions is 4 packages (A,B,C,D) and users who want A will get B, C, and D installed. This in fact was a major selling point of package managers at the time because finding these dependencies by hand and building and merging them all was painful. Many applications break this trend; I don't think golang or nodejs are particularly new (python and ruby have had (pip, venv) and rubygems[1] for years, for example, which are similar bundling paradigms.) The struggle as packagers and distribution managers is when upstream decides "my software should be installed via a bundling solution (golang, node, pip, rubygems, and so on)" we are left to decide both whether to map this to the ebuild paradigm (no bundling of dependencies) or omit ebuilds entirely. In the former case we are often left working at odds with upstream (who are confused by our decomposition of their application) and in the latter case, users often use the bundle anyway (e.g. they install the packages by hand or us
Re: [gentoo-dev] Last rites: media-fonts/symbola
> On Tue, 31 Mar 2020, Ulrich Mueller wrote: > I've sent an e-mail message upstream, asking for confirmation that 10.24 > can be used, copied, modified, and/or distributed freely. This is the answer from upstream (posted here with permission): | The license on https://dn-works.com/ufas/ is the only license ever | issued for UFAS software; it was first posted on my old site two years | ago. | | Pre-license versions of UFAS were accompanied by the “In lieu of a | license” statement: ‘free for any use’. | | That “In lieu of a license” statement is now meaningless. | | Any further clarification, interpretation or fall back to some ‘free | for any use’ versions will constitute a new license; I will not do | this. Basically, this means that we cannot assume that the "free for any use" versions are redistributable, at least not if we want to err on the safe side. This makes symbola-7.17 from 2014 the last free version, which was distributable under the following terms: "Fonts in this site are offered free for any use; they may be installed, embedded, opened, edited, modified, regenerated, posted, packaged and redistributed." https://web.archive.org/web/20141027122717/http://users.teilar.gr/~g1951d/ So, removal of the package seems to be the only option that makes sense, unless we would downgrade to that old version. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] network sandbox challenge
Hi Robin, On 4/1/20 6:36 AM, Robin H. Johnson wrote: >> Normally we don't bundle dependencies, avoiding that problem entirely. >> The Go eclasses however are badly designed, committed against protest by >> paid corporate interests, and serve only to facilitate large-scale >> copyright infringement and security vulnerabilities. If you're looking >> for a consistent explanation of how they're supposed to work with the >> rest of Gentoo, you won't find one. > mjo: Can you please substantiate your claims? > > It would have been nice to have heard your concerns during February, any > of one the three times that William and I posted the go-module.eclass > EGO_SUM development work for review on this mailing list. I don't see a > single email from you during that entire period. > > The EGO_SUM support explicitly ensured that upstream distfiles (for each > dependency) remained absolutely as upstream provided them, without > merging the distfiles together or altering their content in way (I admit > that the exact naming of the distfiles changed, because it was terrible, > v0.0.0-20190311183353-d8887717615a.zip for example). Forgive my noobishness in this matter that let Alec to comment over my own statement. Alec pointed out some very important issues in go development that break copyright infringement and security vulnerabilities, but I'm sure that is not related to the good work done in go-module.eclass to surpass all go mess. npm is worst and I take from go-module as a good pattern to apply also into there. Going back to my overlay use case, will go-modules download all modules to distfiles directory? The naming convention will assure that there will be no modules repetition? What about eclean-dist, will it work as expected for those modules dependencies? I think some of this answers would worth mention in documentation. Sorry for anything I wrongly stated and thank you very much for your help, Samuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] network sandbox challenge
Hi Robin,
On 4/1/20 6:36 AM, Robin H. Johnson wrote:
> Samuel:
> I already proved that using go-module.eclass EGO_SUM it will NOT use Git
> repositories, and all of the fetching will happen long before
> src_unpack. Why do you persist with your statement to the contrary?
Sorry my misunderstanding, but I didn't get it right with what you
mentioned to me before:
> Have you looked at the EGO_SUM in go-module? This already covers ANY go
> package that uses go.mod + go.sum, in a fully reproducible way that does
> not break network sandbox.
I looked into the eclass documentation and I only found EGO_VENDOR[1].
This seems so expensive since I need to parse all go.mod or go.sum files
that I concluded would be better to use a tar.gz with all dependencies
(remember that my use case is with my personal overlay).
Looking deeply into the source code I could find more details about
EGO_SUM that only needs to set the urls to go.mod or/and go.sum files
present in the repository. This is useful, but only to official gentoo
developers, since if I want to use my own mirror type, for instance
mirror://gooverlay, I wouldn't have that option[3]:
> |
> # I am considering removing this and just hard coding mirror://goproxy
> # below, so please do not rely on it.
> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
So, go-module.eclass provides a good base to follow SRP pattern (single
responsibility principle). Looking into that effort I would copy
go-module.eclass to my overlay eclass directory and adapt it to use my
mirror type.
I would like to use directly Gentoo maintained go-module.eclass, but for
that I would like to have access to set my own mirror type.
I also ask you to update documentation since there is some details to
use EGO_SUM, such as you stated in comment[4].
Thanks,
Samuel
[1]
https://devmanual.gentoo.org/eclass-reference/go-module.eclass/index.html
[2] https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass
[3]
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass#n164
[4]
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/go-module.eclass#n31
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] network sandbox challenge
On Wed, 2020-04-01 at 05:36 +, Robin H. Johnson wrote: > On Tue, Mar 31, 2020 at 09:18:32PM -0400, Michael Orlitzky wrote: > > On 3/31/20 8:48 PM, Samuel Bernardo wrote: > > > My question started with the network sandbox issue when we need to load > > > external code dependencies. For example, a go project will download all > > > dependencies from git repositories that will happen after src_unpack. In > > > this case I need to add an additional tar.gz with that code along with > > > the software release tar.gz. > Samuel: > I already proved that using go-module.eclass EGO_SUM it will NOT use Git > repositories, and all of the fetching will happen long before > src_unpack. Why do you persist with your statement to the contrary? > > > > That additional tar.gz needs to be stored somewhere and as I understand > > > local mirror could be the right place. > > > > Normally we don't bundle dependencies, avoiding that problem entirely. > > The Go eclasses however are badly designed, committed against protest by > > paid corporate interests, and serve only to facilitate large-scale > > copyright infringement and security vulnerabilities. If you're looking > > for a consistent explanation of how they're supposed to work with the > > rest of Gentoo, you won't find one. > mjo: Can you please substantiate your claims? > > It would have been nice to have heard your concerns during February, any > of one the three times that William and I posted the go-module.eclass > EGO_SUM development work for review on this mailing list. I don't see a > single email from you during that entire period. > Do you really expect people to repeat themselves every time Go packaging is discussed, and their concerns are ignored because upstream? For one, I've decided to focus on what's new in the eclasses, and just let the tower topple of its own. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] network sandbox challenge
On 4/1/20 1:36 AM, Robin H. Johnson wrote: > mjo: Can you please substantiate your claims? > > It would have been nice to have heard your concerns during February, any > of one the three times that William and I posted the go-module.eclass > EGO_SUM development work for review on this mailing list. I don't see a > single email from you during that entire period. > Seriously?
Re: [gentoo-dev] Last rites: media-fonts/symbola
> "UM" == Ulrich Mueller writes: UM> I've sent an e-mail message upstream, asking for confirmation that 10.24 UM> can be used, copied, modified, and/or distributed freely. cool. i hope useful info results. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
