Re: trusting .deb packages

[Brian]

On Thu 26 Jul 2018 at 01:30:09 +1000, Andrew McGlashan wrote:

> On 25/07/18 23:52, Darac Marjal wrote:
> >> I'm not sure you understand how Debian works, then. Debian is a 
> >> political animal as much as it is technical. There was a
> >> technical requirement for a better init system, so there was a
> >> political process to decide what that would be (I say political
> >> because, although there was a technical committee making the
> >> decision, opinions were sought from the user base, so there was
> >> the possibility of minds being swayed). When the decision to use
> >> systemd was achieved, Debian went down the road of preferring
> >> that as the init system.
> 
> I understand perfectly well, your understanding is shared by many, but
> so too is mine.  There absolutely was NOT a need for a different and
> flawed init system, ABSOLUTELY NOT!

Could we drop this now. Perverting the OP's query to involve a
different topic (one which has been done to death in the past)
gets no one anywhere.

-- 
Brian.

Re: trusting .deb packages

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/07/18 23:52, Darac Marjal wrote:
>> I'm not sure you understand how Debian works, then. Debian is a 
>> political animal as much as it is technical. There was a
>> technical requirement for a better init system, so there was a
>> political process to decide what that would be (I say political
>> because, although there was a technical committee making the
>> decision, opinions were sought from the user base, so there was
>> the possibility of minds being swayed). When the decision to use
>> systemd was achieved, Debian went down the road of preferring
>> that as the init system.

I understand perfectly well, your understanding is shared by many, but
so too is mine.  There absolutely was NOT a need for a different and
flawed init system, ABSOLUTELY NOT!

A.
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAltYl3oACgkQqBZry7fv4vsUNwEArV5LdQAAOeiGK4ROIQZytD+0
6DzE+z2pDU/7vFr5WPUA/jSJiLA5+7w8btY8FgtyZht1B5fp0mSEd6UEhRkP51Iq
=wihe
-END PGP SIGNATURE-

Re: trusting .deb packages

[Darac Marjal]

On Wed, Jul 25, 2018 at 03:54:11PM +1000, Andrew McGlashan wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 25/07/18 07:41, Matthew Crews wrote:

In addition to this, be sure not to break Debian:

https://wiki.debian.org/DontBreakDebian
https://wiki.debian.org/DebianSoftware#Footnotes


"Broken"  many of us strongly believe that once the Debian project
went down the route of systemd, they intrinsically broke Debian and
trust with users; others seem to sincerely believe that systemd is all
good or mostly good.  So, "broken" can be subjective to say the least.


I'm not sure you understand how Debian works, then. Debian is a 
political animal as much as it is technical. There was a technical 
requirement for a better init system, so there was a political process 
to decide what that would be (I say political because, although there 
was a technical committee making the decision, opinions were sought from 
the user base, so there was the possibility of minds being swayed). When 
the decision to use systemd was achieved, Debian went down the road of 
preferring that as the init system. 

Breaking Debian, in this instance, means introducing applications from 
outside the ecosystem. Packages in Debian are, generally speaking, 
tested and reviewed to work with each other. Of course there will be 
incompatibilities, but perhaps a Breaks: header will fix that, or the 
maintainer will push an updated version. With applications from outside 
Debian, though, you don't have that guarantee. Often, packages from 
outside Debian can be quite naive - not working with dpkg-statoverride 
perhaps, or installing files and not removing them on uninstall, or 
perhaps just conflicting with files which ARE in Debian.


What you're talking about, though, isn't breaking Debian per se, but 
breaking Linux/Unix as an ethos. The UNIX ethos is many small tools, 
each doing one thing well. SysV init is a good example of that and 
systemd isn't. But then, one could say that the Linux kernel is not a 
good example of the UNIX ethos, either - it's big and complicated and 
we'd probably all be better off switching to a microkernel.




To me and others whom share my views, Debian is indeed broken like
many other "modern day" Linux distros; one answer is Devuan [1], which
I fully support.

On the whole, I have been very saddened by the path that this project
has taken and I'm hoping that one day it will "right" itself once
again, but I'm not holding my breath as I think the damage to date
(without considering what more badness is to come) has been too great,
there are egos that are too large, and the complexity created is
already far too significant, to reverse this terrible, terrible
decision to "fix" something in such a damaging way.

[1] https://devuan.org

Kind Regards
AndrewM
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAltYEHsACgkQqBZry7fv4vvl2AD+NeJxBjb7+S0uyB7a5oo3MyE0
0FNQ1D0jFvihoz9FhyYBAJOBP+6umtm6iOhZlt3yFI6BRhfefE9U8nJYXu2Gl03L
=6TiA
-END PGP SIGNATURE-




--
For more information, please reread.


signature.asc
Description: PGP signature

Re: trusting .deb packages

[john doe]

On 7/25/2018 7:40 AM, Andrew McGlashan wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/07/18 04:31, john doe wrote:

Also verifying signature using gnupg and checksum is a must
(sha512).


Such verification is suspect, anyone can create gpg keys for anyone
(so trust in the keys used is essential, but more difficult to attain)


Yes, that is why the web of trust is for.

https://en.wikipedia.org/wiki/Web_of_trust


and if you download "supporting" files from a site, then the checksums
and signatures can verify perfectly well . but the product is
still suspect.



You are correct, all relise on the web of trust, which has also flaws.

Checksum will only insure that the file is properly transfered (not 
corrupted).


https://en.wikipedia.org/wiki/Checksum

--
John Doe

Re: trusting .deb packages

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 25/07/18 07:41, Matthew Crews wrote:
> In addition to this, be sure not to break Debian:
> 
> https://wiki.debian.org/DontBreakDebian 
> https://wiki.debian.org/DebianSoftware#Footnotes

"Broken"  many of us strongly believe that once the Debian project
went down the route of systemd, they intrinsically broke Debian and
trust with users; others seem to sincerely believe that systemd is all
good or mostly good.  So, "broken" can be subjective to say the least.

To me and others whom share my views, Debian is indeed broken like
many other "modern day" Linux distros; one answer is Devuan [1], which
I fully support.

On the whole, I have been very saddened by the path that this project
has taken and I'm hoping that one day it will "right" itself once
again, but I'm not holding my breath as I think the damage to date
(without considering what more badness is to come) has been too great,
there are egos that are too large, and the complexity created is
already far too significant, to reverse this terrible, terrible
decision to "fix" something in such a damaging way.

[1] https://devuan.org

Kind Regards
AndrewM
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAltYEHsACgkQqBZry7fv4vvl2AD+NeJxBjb7+S0uyB7a5oo3MyE0
0FNQ1D0jFvihoz9FhyYBAJOBP+6umtm6iOhZlt3yFI6BRhfefE9U8nJYXu2Gl03L
=6TiA
-END PGP SIGNATURE-

Re: trusting .deb packages

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/07/18 12:17, Rick Thomas wrote:
> On Jul 24, 2018, at 2:41 PM, Matthew Crews
>  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?
Kim Dotcom himself has said that he is no longer involved with Mega
and he also stated quite categorically that HE, HIMSELF, does not and
would not trust the current (at that time of him saying at least)
owners...

A.
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAltYDcgACgkQqBZry7fv4vuSdQEAjnvgaNcbzRGpRlsigzz5zBnF
36jKg8s8dQ2LcvWqAa8BAL4BMFDAPOp+Maiau6hhPqFBYZKLuXSMomp0D3YYmmui
=nNEU
-END PGP SIGNATURE-

Re: trusting .deb packages

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/07/18 04:31, john doe wrote:
> Also verifying signature using gnupg and checksum is a must
> (sha512).

Such verification is suspect, anyone can create gpg keys for anyone
(so trust in the keys used is essential, but more difficult to attain)
and if you download "supporting" files from a site, then the checksums
and signatures can verify perfectly well . but the product is
still suspect.

Cheers
A.
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAltYDTgACgkQqBZry7fv4vt0VgEA1Cx87E2K9PHmEULOTERoFUUb
zZiLtUyhoGJBT43DTWkA/jAmGWRc+NxWZ16bRDmWYkwWdy1ArYQbZedfQI75d43+
=9all
-END PGP SIGNATURE-

Re: trusting .deb packages

[Ben Caradoc-Davies]

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  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 
Director
Transient Software Limited 
New Zealand

Re: trusting .deb packages

[Gene Heskett]

On Tuesday 24 July 2018 22:35:17 Matthew Crews wrote:

> On 7/24/18 7:17 PM, Rick Thomas wrote:
> > On Jul 24, 2018, at 2:41 PM, Matthew Crews 
 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?
> >
> > Enjoy!
> > Rick
>
> 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.
>
That, from what I've read in the last 3 or 4 days, is essentially a done 
deal. It was said he's been "detained", presumably so our people can 
pick him up in the middle of the night when they can arrange the flight.

> 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.
>
> 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.
>
> 4. There's always been something shady about Mega that I can't put my
> finger on.

Yeah, I looked at the site once 3 years or so back, and found its thirst 
for personal info plumb scary. Haven't looked since.

> Granted, these aren't the strongest reasons, but for me they are
> strong enough. Maybe I'm wrong though?

Those chances are pretty slim IMO.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: trusting .deb packages

[Matthew Crews]

On 7/24/18 7:17 PM, Rick Thomas wrote:
> 
> On Jul 24, 2018, at 2:41 PM, Matthew Crews  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?
> 
> Enjoy!
> Rick
> 

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.

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.

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.

4. There's always been something shady about Mega that I can't put my
finger on.

Granted, these aren't the strongest reasons, but for me they are strong
enough. Maybe I'm wrong though?

Re: trusting .deb packages

[Rick Thomas]

On Jul 24, 2018, at 2:41 PM, Matthew Crews  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?

Enjoy!
Rick

Re: trusting .deb packages

[Ben Caradoc-Davies]

On 25/07/18 13:04, Anil Duggirala wrote:

Also consider using the open-source megatools package. 1.10.0 has just
been released and is expected in Debian soon.

megatools 1.10.0 has just been accepted into unstable and is in the
build queue.

I did make a search and found this package, an older version 1.9.98-1 which 
seems really old, so decided to go with the .deb package. I wasnt sure if such 
an old package would work correctly with the service,
thanks a lot,


1.9.98-1+b1 has stopped working reliably with the Mega service. This 
problem, related to the use of TLS for uploads and causing them to 
sometimes hang, has been fixed in 1.10.0:


Bug#904058: megatools: megaput hangs at 100% upload
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904058

The builds completed minutes ago. I have just installed megatools 
1.10.0-1 hot off incoming. It is not yet even in unstable:

https://incoming.debian.org/debian-buildd/pool/main/m/megatools/megatools_1.10.0-1_amd64.deb

megadf and megals from megatools 1.10.0-1 work for me on unstable. I 
have not tried megaput.


For 1.9.98-1, the .deb for unstable needed a +b1 binary rebuilt against 
libcurl4. It looks like 1.10.0 has been built against libcurl4, which is 
not present on stretch, so you may need a package built for stretch.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: trusting .deb packages

[Anil Duggirala]

> > Also consider using the open-source megatools package. 1.10.0 has just 
> > been released and is expected in Debian soon.
> 
> megatools 1.10.0 has just been accepted into unstable and is in the 
> build queue.
> 

I did make a search and found this package, an older version 1.9.98-1 which 
seems really old, so decided to go with the .deb package. I wasnt sure if such 
an old package would work correctly with the service,
thanks a lot,

Re: trusting .deb packages

[Ben Caradoc-Davies]

On 25/07/18 09:51, Ben Caradoc-Davies wrote:

On 25/07/18 03:45, Anil Duggirala wrote:
I am thinking about installing the Mega.nz app on my Debian Stretch 
installation. They provide a .deb package. Is there anything I can do 
to ensure this is a safe package? To know that this package will not 
create a security vulnerability on my system? What is the minimum 
security procedure to follow when installing third party provided .deb 
packages?
Also consider using the open-source megatools package. 1.10.0 has just 
been released and is expected in Debian soon.


megatools 1.10.0 has just been accepted into unstable and is in the 
build queue.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: trusting .deb packages

[Ben Caradoc-Davies]

On 25/07/18 03:45, Anil Duggirala wrote:

I am thinking about installing the Mega.nz app on my Debian Stretch 
installation. They provide a .deb package. Is there anything I can do to ensure 
this is a safe package? To know that this package will not create a security 
vulnerability on my system? What is the minimum security procedure to follow 
when installing third party provided .deb packages?


Also consider using the open-source megatools package. 1.10.0 has just 
been released and is expected in Debian soon.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: trusting .deb packages

[Matthew Crews]

‐‐‐ Original Message ‐‐‐
On July 24, 2018 9:43 AM, Dan Ritter  wrote:

> On Tue, Jul 24, 2018 at 10:45:38AM -0500, Anil Duggirala wrote:
>
> > I am thinking about installing the Mega.nz app on my Debian Stretch 
> > installation. They provide a .deb package. Is there anything I can do to 
> > ensure this is a safe package? To know that this package will not create a 
> > security vulnerability on my system? What is the minimum security procedure 
> > to follow when installing third party provided .deb packages?
>
> Do you trust the people who wrote it?
>
> Do they provide the source?
>
> Do they give you instructions on how to build the source into a
> package?
>
> Are you competent to read and understand the source?
>
> What do you stand to lose if you place your trust in them and it
> turns out that they were incompetent or evil?
>
> -dsr-

In addition to this, be sure not to break Debian:

https://wiki.debian.org/DontBreakDebian
https://wiki.debian.org/DebianSoftware#Footnotes

Personally, I have a low degree of trust for Mega.nz, so caveat emptor.

Re: trusting .deb packages

[john doe]

On 7/24/2018 6:43 PM, Dan Ritter wrote:

On Tue, Jul 24, 2018 at 10:45:38AM -0500, Anil Duggirala wrote:

I am thinking about installing the Mega.nz app on my Debian Stretch 
installation. They provide a .deb package. Is there anything I can do to ensure 
this is a safe package? To know that this package will not create a security 
vulnerability on my system? What is the minimum security procedure to follow 
when installing third party provided .deb packages?



Do you trust the people who wrote it?

Do they provide the source?

Do they give you instructions on how to build the source into a
package?

Are you competent to read and understand the source?

What do you stand to lose if you place your trust in them and it
turns out that they were incompetent or evil?



Also verifying signature using gnupg and checksum is a must (sha512).

--
John Doe

Re: trusting .deb packages

[Anil Duggirala]

Thanks Dan, your questions answer my question. In this case they do provide the 
source code, which am not competent enough to understand, but I do trust them.
thanks a lot,

Re: trusting .deb packages

[Dan Ritter]

On Tue, Jul 24, 2018 at 10:45:38AM -0500, Anil Duggirala wrote:
> I am thinking about installing the Mega.nz app on my Debian Stretch 
> installation. They provide a .deb package. Is there anything I can do to 
> ensure this is a safe package? To know that this package will not create a 
> security vulnerability on my system? What is the minimum security procedure 
> to follow when installing third party provided .deb packages?


Do you trust the people who wrote it?

Do they provide the source?

Do they give you instructions on how to build the source into a
package?

Are you competent to read and understand the source?

What do you stand to lose if you place your trust in them and it
turns out that they were incompetent or evil?

-dsr-