Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #197972

Re: trusting .deb packages

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

Show all headers | View raw


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


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