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

Groups > linux.debian.user > #197957 > unrolled thread

trusting .deb packages

Back to article view | Back to linux.debian.user

Contents

  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

#197957 — trusting .deb packages

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?
thanks,

[toc] | [next] | [standalone]

#197959

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-

[toc] | [prev] | [next] | [standalone]

#197960

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,

[toc] | [prev] | [next] | [standalone]

#197961

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

[toc] | [prev] | [next] | [standalone]

#197974

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

[toc] | [prev] | [next] | [standalone]

#197977

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

[toc] | [prev] | [next] | [standalone]

#197963

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 24, 2018 9:43 AM, Dan Ritter <dsr@randomstring.org> 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.

[toc] | [prev] | [next] | [standalone]

#197969

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?

Enjoy!
Rick

[toc] | [prev] | [next] | [standalone]

#197970

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

[toc] | [prev] | [next] | [standalone]

#197971

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 
<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?
> >
> > 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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#197972

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

[toc] | [prev] | [next] | [standalone]

#197973

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

[toc] | [prev] | [next] | [standalone]

#197975

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

[toc] | [prev] | [next] | [standalone]

#197986

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#197989

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

[toc] | [prev] | [next] | [standalone]

#197990

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.

[toc] | [prev] | [next] | [standalone]

#197964

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 <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#197966

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 <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#197967

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

[toc] | [prev] | [next] | [standalone]

#197968

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 <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web