Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Kent Fredric
On Wed, 8 Apr 2020 17:39:54 +
Peter Stuge  wrote:

> E.g. for auditing the installed values of these could be worth a lot.

Only as far as analyising "why was this package installed, currently
the metadata says its un-audited!".

But for things like "affected by CVE/Bug", the very nature of those is
they're often post-install metadata, so one should not be required to
change an ebuild and reinstall the ebuild if that metadata has to
change.

And say, if a currently installed package had its "audit check marker"
removed from the metadata, portage should react to that immediately and
treat the installed package as bad.

The "what was the metadata when this package was installed" would only
help portage clarify the output message.



pgpSNSjOkuiFo.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Peter Stuge
Kent Fredric wrote:
> Syntax above not expected verbatim, just food for thought,

I think this is a really good and useful idea. I would love to see it.


> the nature of this metadata is that it SHOULD NOT be in the ebuild
> itself, as it is inherently "repo based", the installed values of
> these are worthless.

E.g. for auditing the installed values of these could be worth a lot.


Thanks!

//Peter



Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Kent Fredric
On Tue, 07 Apr 2020 14:44:04 +0100
Roy Bamford  wrote:

> Gentoo must not single out any package for special treatment.

Indeed. Cases like this just demonstrate that something about the way
we do things is somehow inadequate.

The idea that "what we have works" is something we get away with,
because people just exclude the things that would break things.

Sometimes you just need some case like this to make an example of us.

Like happened with Rust:

- It took a while and a bunch of legal threats for them to publish a
  GDPR compliance privacy notice.
- They (crates.io) still haven't made a clear definition of what legal
  conditions apply and what may or may not be uploaded (Some people are
  presently testing those waters by publishing code with copyright
  notices and "no distribution" clauses, in the hope they can get their
  ass into gear and make it clear )

And I've seen people "test the system" for CPAN too.

Its clear we need *something* in place, but I doubt that "something" is
something that can be achieved in an appropriate way with the way our
tooling currently works.

( In that, its basically an all-or-nothing scenario for the most part,
where finer grained and policy-based exlusions, like ACCEPT_LICENSE,
make sense to employ )


pgpsQPxoI_VM5.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Kent Fredric
On Tue, 7 Apr 2020 12:47:33 +0200
Thomas Deutschmann  wrote:

> Sure, that could have banal reasons like "No one audited the Linux
> version yet". But in security you don't issue warnings if you aren't
> sure. Because if you make false statements people will no longer trust
> you. But trust is everything.

Agree.

In line with my other suggestions with exposing this via in-repo
meta-data, there probably should be a facility in a future EAPI that
allows one to both know about this /class/ of risk, and address it.

So for instance:

ACCEPT_ASPECTS="bug:45678 bug:14678 cve:COVID-19 trust:proprietary"

Or something.

The gist being that say, zoom could have:

 > net-im/zoom  trust:proprietary

As could anything that is both shipped as a binary blob, not produced
by somebody on gentoo staff, and has no source available. 

For instance, if the source is available, but its a 3rd party binary,
there could potentially be a step in shipping that puts unaudited code
in the binary, so its not smart to say its entirely as-bad as something
that is unaudited, but *some* caution should be taken.

If a user locally wants to, by policy, avoid all packages that are
either unaditable, or have some weaknesses around their auditabilty, we
should provide tools to do that.

Syntax above not expected verbatim, just food for thought, but its
worth mentioning that bug/cve/trust levels don't always map 1:1 with packages, 
and also, that the nature of this metadata is that it SHOULD NOT be
in the ebuild itself, as it is inherently "repo based", the installed
values of these are worthless.

Running with the idea a bit here: 

It would even be possible for a 3rd party overlay to contain *only* a
trove of these aspects, and then a controlled deployment could have a local

REQUIRED_ASPECTS="trust:team-sec" ( where team-sec is defined by said overlay )

Which requires all packages you install on your system have some sort
of metadata indicating that they've been signed off by team-sec. (
either the whole cat/pn, or some versions there of )


pgpFBOb9vl43a.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Roy Bamford
On 2020.04.07 09:48, Ulrich Mueller wrote:
> > On Tue, 07 Apr 2020, Samuel Bernardo wrote:
> 
> > No assurance is also a level that takes place in the lower ranking
> > level. If someone needs to use zoom because they are demanded by
> their
> > boss I think that would be even more useful to know that it is
> possible
> > to install zoom in Gentoo and that is rated as the worst possible
> > software. Maybe this would allow others to join our zoom claim...
> 
> We could add a README.gentoo file with our caveats. It won't be
> perfect,
> but maybe better than nothing. (And certainly better than displaying a
> warning on every upgrade, which will eventually annoy people [1].)
> 
> Any suggestions for a wording?
> 
> Ulrich
> 
> 
> [1] https://bugs.gentoo.org/416769
> 

Team,

Just 'No.' 

Its not useful to anyone to single out a single binary only package 
for special treatment.

Lets compare zoom to firefox-bin as a worked example.
Nobody except Mozilla knows whats in firefox-bin. Gentoo doesn't 
build it, its the official Mozilla binary build.

Mozilla distubute source code too. There is no assurace that they 
are the sources used to build firefox-bin.

Over the years Firefox has had its share of CVEs.
How is firefox-bin any different to zoom?

I've only selected firefox-bin as a worked example. There are other 
binary packages in ::gentoo. In the same boat.

They all need to be treated consistently.


Then there is the question of the liability exposure.
There are two prongs to this.

a) any advice will be incomplete and or out of date.
That will damage trust.

b) one day, it will be plain wrong and zoom or whoever will get very 
upset and be able to prove it.

Its OK to publish advice based on beliefs or opinions, there is no 
requirement for beliefs or opinions to be based on fact but we are
not discussing beliefs or opinions here.

In summary, we can't be sure of our facts. We can't be sure that 
any warning complete and correct.

Gentoo must not single out any package for special treatment.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpv44y3BnnyV.pgp
Description: PGP signature


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Thomas Deutschmann
On 2020-04-07 12:35, Alessandro Barbieri wrote:
> What about moving all of these binary-only packages in an official overlay
> (made for the scope) or in GURU?

And which problem is that going to solve?

Do we want to tell world, "Look! Gentoo is the most secure distribution!
We have zero vulnerabilities*!"

*Because we move vulnerable packages to an overlay!

Please, don't get me wrong. But the whole thread looks like pure
activism to me. It looks like most people don't understand any details
but have the feeling "but we must do *anything*". This ignores the fact,
that most discussed issues in Zoom for example are found/caused by the
installer. Something we don't have in the Linux version. Or requires
write access into Zoom application directory which also doesn't affect
us (this is BTW a can Google opened years ago when they tried to get
market shares and were looking for a way to allow users to just install
their software without asking their IT department. Since then it became
'normal' to install software in user profile. The problem: This allows
any user process to modify these files, plant exploits to abuse
vulnerable loaders and stuff like that you don't have when you do proper
ACLs).

Regarding bin/non-bin: Software has bugs. Some software tends to have
more issues. Just because we have the source code and compile software
on user's system doesn't make the application itself more secure than
the provided binary package.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Thomas Deutschmann
On 2020-04-07 10:48, Ulrich Mueller wrote:
> We could add a README.gentoo file with our caveats. It won't be perfect,
> but maybe better than nothing. (And certainly better than displaying a
> warning on every upgrade, which will eventually annoy people [1].)

I am strictly against something like this.

We have a lot of packages with *confirmed* *serious* problems. Zoom is
not special to warrant a special treatment in any way.

More important: Until today, not one single vulnerability discussed in
public recently got confirmed for the Linux version.

Sure, that could have banal reasons like "No one audited the Linux
version yet". But in security you don't issue warnings if you aren't
sure. Because if you make false statements people will no longer trust
you. But trust is everything.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Alessandro Barbieri
What about moving all of these binary-only packages in an official overlay
(made for the scope) or in GURU?

Il Gio 2 Apr 2020, 02:48 Rich Freeman  ha scritto:

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


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Ulrich Mueller
> On Tue, 07 Apr 2020, Samuel Bernardo wrote:

> No assurance is also a level that takes place in the lower ranking
> level. If someone needs to use zoom because they are demanded by their
> boss I think that would be even more useful to know that it is possible
> to install zoom in Gentoo and that is rated as the worst possible
> software. Maybe this would allow others to join our zoom claim...

We could add a README.gentoo file with our caveats. It won't be perfect,
but maybe better than nothing. (And certainly better than displaying a
warning on every upgrade, which will eventually annoy people [1].)

Any suggestions for a wording?

Ulrich


[1] https://bugs.gentoo.org/416769


signature.asc
Description: PGP signature


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Kent Fredric
On Mon, 6 Apr 2020 23:55:07 +0100
Samuel Bernardo  wrote:

> This is the kind of useful information that we could collect from the
> QA, extending the greatness of the best distro ever made. The
> availability of software from a distro is better than installing it
> standalone, allowing to share knowledge about relevant information such
> as security, maintenance, ...

Indeed.

I've long wanted some sort of capacity for:

- Portage to be capable of correlating packages and their versions
  with known bugs that affect those versions 

- Portage to be capable of correlating packages and relative CVE's.

Presently all we end up doing is:

- Oh no, it has a bug, remove it!
- Or in more careful conditions, P.Mask it with reasons

The best tool we have to solve even part of this problem is glsa-check,
but its not mainstream enough.

So we simply don't have the /tools/ required for general users to make
decisions about "should I upgrade?", "should I remove this?" beyond
"oh, its gone", or "oh, its package masked"

But utlimately, this is not a technology problem: Its a staffing problem.

We simply don't have the power to keep old things or vulnerable things
around for people to use "if they're clever"

( And every additional version aggregates to exponential complexity
creating more places for portage to get confused )

For top level binary things like zoom, its easier due to nothing
depending on it.

But handling such things for vulnerable or buggy dependencies, things
get tricky quickly.


pgps5Ss0y7dMe.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-06 Thread Samuel Bernardo
Hi Kent,

On 4/6/20 2:08 PM, Kent Fredric wrote:
> So no, nobody can actually make assurances of this software, we can
> only stipulate which cautions we know are warranted.

No assurance is also a level that takes place in the lower ranking
level. If someone needs to use zoom because they are demanded by their
boss I think that would be even more useful to know that it is possible
to install zoom in Gentoo and that is rated as the worst possible
software. Maybe this would allow others to join our zoom claim...

This is the kind of useful information that we could collect from the
QA, extending the greatness of the best distro ever made. The
availability of software from a distro is better than installing it
standalone, allowing to share knowledge about relevant information such
as security, maintenance, ...

Best,

Samuel




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-06 Thread Kent Fredric
On Sun, 5 Apr 2020 17:11:01 +0100
Samuel Bernardo  wrote:

> Sorry about my comment, but couldn't that be solved choosing the right
> profile or opting for an official overlay, raking the assurance level of
> those?

If zoom is a binary only package, not opensource, we can't make any
assurances.

Even if the source is available, if we're not shipping variations of it
compiled by our tools, there could be arbitrary un-evaluated extensions
hiding in it.

So no, nobody can actually make assurances of this software, we can
only stipulate which cautions we know are warranted.


pgpfoL9I88gm7.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-05 Thread Samuel Bernardo
On 2020-04-04 15:57, Kent Fredric wrote:
> Depends how concerned you are about VM busting exploits contaminating
> the host.
>
> ( Maybe not Zoom in particular, but with regard to the general theme of
> "risky apps on a valued system" )

Sorry about my comment, but couldn't that be solved choosing the right
profile or opting for an official overlay, raking the assurance level of
those?

Moving away the goodwill of those maintainers that get software into
Gentoo I think is not the good way...

Giving my opinion, maybe it should be useful to have QA classification
in future Gentoo Build System, where each overlay and profile could get
their ranking (from the automatic classifiers along with optional human
review)... Just a thought




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-04 Thread Kent Fredric
On Thu, 2 Apr 2020 10:01:57 +0200
Michal Prívozník  wrote:

> Alternatively, you can set up a VM that contains nothing but the bare
> minimum required to run app X and assign webcam to it, for instance.
> Having said that, I'd still love the packaging system to install the app
> as it resolves all the dependencies, etc.

Depends how concerned you are about VM busting exploits contaminating
the host.

( Maybe not Zoom in particular, but with regard to the general theme of
"risky apps on a valued system" )


pgpZUwFC4DHyF.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-04 Thread Kent Fredric
On Wed, 1 Apr 2020 17:53:39 -0700
Alec Warner  wrote:

> you cannot accept arbitrary long
> passwords

Sure you can, as long as you're not storing them anywhere, and are
instead, storing their checksum of some kind.

Then the only limitations really are how much memory and time you have
to locally buffer your password while the checksum computes it :)

Nobody stores passwords right? Right?

(/me then socially distances from the internet)


pgprEtA_hfOHJ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Thomas Deutschmann
Hi,

it's true that zoom is currently getting a lot of attention. It all
started with the iOS application using Facebook SDK to provide login
through Facebook and their TOS/privacy statement.

That triggered a lot of (security) researchers who are currently sitting
at home like most people in western world with a lot of time. If
upstream will address all problems this will become one of the best
(free-)audited conference software available ;-)

For this discussion please keep in mind that there are multiple versions
for different platforms. Not every platform is affected by all reported
problems.

Regarding zoom and Gentoo: net-im/zoom doesn't require any special
handling in Gentoo. Package is not even marked stable. We have a lot of
vulnerable packages...

If problems will get confirmed for the available Linux version and
upstream won't provide a fix within ~12 months (depends on severity of
reported vulnerabilities) we maybe decide to last-rite or apply a mask
to force user awareness through forced unmask action in case they need
that software. But again, this software isn't special and doesn't
require further discussion from our P.O.V.


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Ulrich Mueller
> On Thu, 02 Apr 2020, Rich Freeman wrote:

> I guess we could stick an einfo in the post-install messages,

Not sure if that's necessary. Zoom is a proprietary, closed-source,
fetch-restricted package, so users should know that they cannot expect
the same level of quality as for free software. (In the default
configuration, it is license-masked, so users must explicitly unmask
it before installation.)

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

+1

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Ulrich Mueller
> On Thu, 02 Apr 2020, Alessandro Barbieri wrote:

> I have concerns about the inclusion of zoom in ::gentoo. For me it's
> more like a malware.

Gentoo is about choice. If users want to use Zoom (or have to, because
their employer schedules a meeting using that platform) then it is not
our call to stop them.

> 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

Right, and I (as its Gentoo maintainer) won't recommend Zoom to anyone,
nor use it myself unless I am forced to.

However, if we would remove the package from the Gentoo repo, users
would inevitably install it from one of the overlays listed at
https://gpo.zugaina.org/net-im/zoom-bin (there are even more, named
net-im/zoom or app-office/zoom), which vary in quality. Most of them
install bundled libraries which are old and vulnerable, e.g. Qt 5.9.6.

I believe that the number of overlays (more than a dozen) containing the
package shows that there is demand for it. In the main tree we have at
least a chance to address bug reports.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Michal Prívozník
On 2. 4. 2020 7:51, Michał Górny wrote:
> 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.
> 

Alternatively, you can set up a VM that contains nothing but the bare
minimum required to run app X and assign webcam to it, for instance.
Having said that, I'd still love the packaging system to install the app
as it resolves all the dependencies, etc.

Michal




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