Re: [gentoo-dev] zoom concerns
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
> 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
> 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
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
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] 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
