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

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

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

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

[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

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. > >>> :

[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

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 >

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

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.

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

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

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

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 >

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

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

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

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,

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

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