Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #197972
| From | Ben Caradoc-Davies <ben@transient.nz> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: trusting .deb packages |
| Date | 2018-07-25 05:40 +0200 |
| Message-ID | <wfiOB-7UY-1@gated-at.bofh.it> (permalink) |
| References | <wf7Jw-8gM-3@gated-at.bofh.it> <wf8FA-xm-11@gated-at.bofh.it> <wfdlT-3WS-3@gated-at.bofh.it> <wfhSx-7i1-9@gated-at.bofh.it> <wfhSy-7i1-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 25/07/18 14:35, Matthew Crews wrote: > On 7/24/18 7:17 PM, Rick Thomas wrote: >> On Jul 24, 2018, at 2:41 PM, Matthew Crews <mailinglists@mattcrews.com> wrote: >>> Personally, I have a low degree of trust for Mega.nz, so caveat emptor. >> Why do you say that? (serious question!) Have there been reports of problems? > A few reasons: > 1. Kim Dotcom vs the United States. There is a strong chance Mr. Dotcom > will be extradited to the United States (due to Megaupload and other > criminal accusations), and will leave Mega without functional leadership. Apparently, Kim Dotcom is no longer associated with Mega: https://en.wikipedia.org/wiki/Mega_(service) > 2. In light of Megaupload being shut down, there's no guarantee that > Mega won't have the same fate at some point, considering the services > are basically identical. How do they differ from any other cloud storage provider, other than having support for client-side encryption? Nothing stops copyright infringers from uploading encrypted blobs to Amazon S3 and sharing links and keys. Their business model, which was the basis for the closure of Megaupload, seems quite different. Was Megaupload encrypted? I do not recall that it was: https://en.wikipedia.org/wiki/Megaupload What led (allegedly) to Kim Dotcom's downfall was threatening the business model of the media-industrial complex and (allegedly) boasting about it on chat: https://en.wikipedia.org/wiki/Megaupload_legal_case The indictment is not clear cut and yet to be examined by the courts: https://en.wikipedia.org/wiki/Megaupload_legal_case#Basis_of_indictment Kim Dotcom has kept the New Zealand public entertained for years: https://en.wikipedia.org/wiki/Kim_Dotcom https://en.wikipedia.org/wiki/Internet_Party_(New_Zealand) > 3. Their server software is not auditable. Even though the client-side > and API are public, unless the server side is auditable, you cannot > effectively trust it any better than Google Drive or Dropbox. Of course, > few storage providers are, and even if they are, you should be using > client-side encryption that you control, anyway. If you are using megatools, you are already using open source client-side encryption software that you control. And if you are super-paranoid, double-encrypt with "gpg --symmetric --cipher-algo AES256 --s2k-digest-algo SHA512" using a different passphrase before uploading. > 4. There's always been something shady about Mega that I can't put my > finger on. The whole internet is a bit shady. Perhaps Mega are behind fluoridation and chemtrails? The whole point of client-side encryption is that you do not have to trust them. > Granted, these aren't the strongest reasons, but for me they are strong > enough. Maybe I'm wrong though? You may be proven right, but, because it is impossible to prove a negative, you will never be proven wrong. Kind regards, -- Ben Caradoc-Davies <ben@transient.nz> Director Transient Software Limited <https://transient.nz/> New Zealand
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
trusting .deb packages Anil Duggirala <anilduggirala@fastmail.fm> - 2018-07-24 17:50 +0200
Re: trusting .deb packages Dan Ritter <dsr@randomstring.org> - 2018-07-24 18:50 +0200
Re: trusting .deb packages Anil Duggirala <anilduggirala@fastmail.fm> - 2018-07-24 20:00 +0200
Re: trusting .deb packages john doe <johndoe65534@mail.com> - 2018-07-24 20:40 +0200
Re: trusting .deb packages Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-07-25 07:50 +0200
Re: trusting .deb packages john doe <johndoe65534@mail.com> - 2018-07-25 11:40 +0200
Re: trusting .deb packages Matthew Crews <mailinglists@mattcrews.com> - 2018-07-24 23:50 +0200
Re: trusting .deb packages Rick Thomas <rbthomas@pobox.com> - 2018-07-25 04:40 +0200
Re: trusting .deb packages Matthew Crews <mailinglists@mattcrews.com> - 2018-07-25 04:40 +0200
Re: trusting .deb packages Gene Heskett <gheskett@shentel.net> - 2018-07-25 05:20 +0200
Re: trusting .deb packages Ben Caradoc-Davies <ben@transient.nz> - 2018-07-25 05:40 +0200
Re: trusting .deb packages Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-07-25 07:50 +0200
Re: trusting .deb packages Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-07-25 08:00 +0200
Re: trusting .deb packages Darac Marjal <mailinglist@darac.org.uk> - 2018-07-25 16:00 +0200
Re: trusting .deb packages Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-07-25 17:40 +0200
Re: trusting .deb packages Brian <ad44@cityscape.co.uk> - 2018-07-25 17:50 +0200
Re: trusting .deb packages Ben Caradoc-Davies <ben@transient.nz> - 2018-07-25 00:00 +0200
Re: trusting .deb packages Ben Caradoc-Davies <ben@transient.nz> - 2018-07-25 02:30 +0200
Re: trusting .deb packages Anil Duggirala <anilduggirala@fastmail.fm> - 2018-07-25 03:10 +0200
Re: trusting .deb packages Ben Caradoc-Davies <ben@transient.nz> - 2018-07-25 03:40 +0200
csiph-web