Re: [gentoo-dev] zoom concerns

2020-04-01 Thread Michał Górny
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

2020-04-01 Thread William Kenworthy
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

2020-04-01 Thread Alec Warner
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

2020-04-01 Thread Rich Freeman
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

2020-04-01 Thread Andreas Sturmlechner
# 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

2020-04-01 Thread Alessandro Barbieri
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

2020-04-01 Thread Robin H. Johnson
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.

2020-04-01 Thread Piotr Karbowski
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

2020-04-01 Thread Robin H. Johnson
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

2020-04-01 Thread Samuel Bernardo
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

2020-04-01 Thread Robin H. Johnson
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

2020-04-01 Thread Michael Orlitzky
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

2020-04-01 Thread Samuel Bernardo
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

2020-04-01 Thread James Cloos
> "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

2020-04-01 Thread Samuel Bernardo
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.) 

Re: [gentoo-dev] network sandbox challenge

2020-04-01 Thread Michael Orlitzky
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

2020-04-01 Thread Alec Warner
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 

Re: [gentoo-dev] Last rites: media-fonts/symbola

2020-04-01 Thread Ulrich Mueller
> 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

2020-04-01 Thread Samuel Bernardo
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

2020-04-01 Thread Samuel Bernardo
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

2020-04-01 Thread Michał Górny
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

2020-04-01 Thread Michael Orlitzky
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

2020-04-01 Thread James Cloos
> "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