Re: Privacy policy of packages/softwares installed in Debian

[npdflr]

Thanks Jean for your reply.



Non-free packages should definitely be checked with their privacy policy. But 
what about free packages?


The license for the Go programming language is https://golang.org/LICENSE which 
is free but the privacy policy is invasive 
https://policies.google.com/privacy?hl=en

(Note: it also has a patent file with some restrictions which can make the 
package non-free perhaps, would give more details if required)


Free networking applications like browsers, p2p applications etc would 
definitely require internet but other free apps also connect with the internet 
automatically when starting for the first time (Eg: aseprite, libreoffice) or 
when checking for updates. One can know this via an application-based firewall.

Free packages are available via main repositories (through terminal  apt 
commands or a package manager) and also via 
other ways like websites, terminal commands like wget, curl etc, offline 
archive files 
etc.

Would you say that all free packages via main repositories and via other ways 
(after checking their license to be DFSG-compliant) can be safely be allowed to 
connect to the internet?

Thanks.



 On Sun, 09 Jun 2019 05:49:01 -0700 Jean-Philippe MENGUAL 
 wrote 




Hi,



Privacy policy makes sense for software you quote, eithr because
they are closd-code, or because thy are in the cloud and users send
data to servers, so it is important to know what do this data once
sent.



Debian provides free software and does not support non-free one even
if they exist in the Debian infra. They provide tools to be
installed on your computer. So when you install a program in Debian,
you can check the code, but more important, you dont send data to an
external source.



Then I dont think Debian needs a privacy policy. Neither Debian, nor
the packages themselves collect the user data. And it would be a
problem to do this, from the socail contract.



I think we can consider having a thought about it if some program
collects data. For a non free program, this should be in its licene
or on th websie of its provider.



Regards









Jean-Philippe MENGUAL


Le 08/06/2019 à 20:02, npdflr a écrit :






Hello,

How can one check the privacy policy for the
  packages/softwares (which can be free or non-free) installed
  in Debian?



If one is downloading and installing a package from a
  website then he/she can check the privacy policy link on that
  website.

Example:

-- Skype (https://www.skype.com/en/get-skype/)
  which has privacy policy: 
https://privacy.microsoft.com/en-US/privacystatement

-- Go programming language (https://golang.org/)
  which has privacy policy: https://policies.google.com/privacy?hl=en



But if one is downloading a package (which may also install
  dependency packages) via terminal or synaptic package manager
  then how can one check the privacy policy of that package?



Thank you.

Re: How could I install ecryptfs-utils on Buster

[andreimpopescu]

On Mi, 10 apr 19, 15:40:13, Pierre Fourès wrote:
> 
> I did the test and all went as expected. I got ecryptfs-utils being
> installed with the four of its dependencies. One of them, keyutils, is
> in 1.5.9-9 in stretch and 1.6.6 in buster. As expected, apt installed
> the one from buster. After the install, I then had precisely the same
> packages installed in the same versions as what it was before
> ecryptfs-utils was removed from buster. This kind of satisfy my «
> simple and easy » solution requirement.

Your solution (mix stretch with buster) is pretty safe.

Just for your peace of mind, you could provide additional hints to APT 
like setting Default-Release to "buster".
 
> I just have one minor consideration about this. It was about adding
> stretch-security on top of it. In the case ecryptfs would be updated,
> I would like to take this upgrade. But I'm not sure this would play
> well regarding other packages being in the same version number between
> stretch and buster. 

Version numbers in release-security are specifically chosen to "play 
nice" with version numbers in release+1 (otherwise full/dist-upgrades 
wouldn't work), so updating from stretch-security should be safe, even 
more so with the Default-Release setting proposed above.

As an additional safeguard you could also use pinning to tell APT that 
you only want encryptfs (and dependencies) from stretch (priority 100), 
and pin the rest of stretch to a lower priority (e.g. 1).

One other possibility that I didn't see mentioned in this thread would 
be to make a forward port to buster of the stretch encryptfs package in 
case buster diverges too much from stretch and makes it uninstallable.

Considering that buster is in deep freeze the probability for this to 
happen is quite low though.


Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Privacy policy of packages/softwares installed in Debian

[tomas]

On Mon, Jun 10, 2019 at 12:08:04AM -0700, npdflr wrote:
> Thanks Jean for your reply.
> 
> Non-free packages should definitely be checked with their privacy policy. But 
> what about free packages?

Agreed.

> The license for the Go programming language is https://golang.org/LICENSE 
> which is free but the privacy policy is invasive 
> https://policies.google.com/privacy?hl=en

This is, at least, debatable. Go deems itself independent from Google
(formally it is; whether it is "de facto" is a much more difficult
question).

> Would you say that all free packages via main repositories and via other ways 
> (after checking their license to be DFSG-compliant) can be safely be allowed 
> to connect to the internet?

This is a very good question, and I think there's no clear-cut
answer to it. When Debian and its Social Contract [0] were conceived,
the focus was more on giving end users power through free software.

Nowadays free software has "won" (of sorts), but the lines of
conflict have shifted to a more subtle "place". Most of the software
a Facebook user is in contact with is somehow "free". Heck, FB is
one important contributor to the Linux kernel. But... would you say
a FB user controls his/her use of FB? Tough call.

To illustrate the point you made a bit better, I've seen Google
beacons embedded in the Javascript included in free packages[1].

Free but... privacy respecting? Up to debate.

You can help making Debian better by trying to find such things
and reporting them as bugs. I think most Debian maintainers would
agree that those go against the spirit of the Social Contract [0].

Cheers
[0] https://www.debian.org/social_contract

[1] In one case, a web app testing package, there was even a
   comment in there "please, leave this in, since that's how
   we make money", so the inclusion was not an accident. In
   the other case, it was in a Debian package -- this one has
   disappeared since, otherwise I'd have filed a bug report.

-- tomás


signature.asc
Description: Digital signature

Re: How to set access permissions to protect a database file?

[john doe]

On 6/10/2019 7:56 AM, Reco wrote:
>   Hi.
>
> On Sun, Jun 09, 2019 at 06:32:42PM -0300, Markos wrote:
>> Many thanks to Mick, David and Joe,
>>
>> To guarantee "some" protection to the file containing the database I decided 
>> to use the following strategy:
>>
>> I created, as root, the directory /home/reading_room
>>

Is '/home/reading_room' a defined user on the host?
If no, choosing a home directory with an non-existing user might not be
the best idea.


https://www.debian.org/releases/stable/i386/apcs02.html.en

--
John Doe

Re: What is agetty, and why can't it be stopped?

[Curt]

On 2019-06-06, Gene Heskett  wrote:
>   
> What do I do next to get rid of this nearly invisible agetty gizmo once 
> this machine is booted?  It might be handy if this machine is truly 
> hung, but I can count those instances on one hand with fingers left over 
> in the 21 years I have been a linux only house.

Maybe

sudo systemctl stop serial-getty@ttyS0.service

if you haven't already tried it.


> Thanks all;
>
> Cheers, Gene Heskett


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: Privacy policy of packages/softwares installed in Debian

[Gene Heskett]

On Monday 10 June 2019 04:11:54 am to...@tuxteam.de wrote:

> On Mon, Jun 10, 2019 at 12:08:04AM -0700, npdflr wrote:
> > Thanks Jean for your reply.
> >
> > Non-free packages should definitely be checked with their privacy
> > policy. But what about free packages?
>
> Agreed.
>
> > The license for the Go programming language is
> > https://golang.org/LICENSE which is free but the privacy policy is
> > invasive https://policies.google.com/privacy?hl=en
>
> This is, at least, debatable. Go deems itself independent from Google
> (formally it is; whether it is "de facto" is a much more difficult
> question).
>
> > Would you say that all free packages via main repositories and via
> > other ways (after checking their license to be DFSG-compliant) can
> > be safely be allowed to connect to the internet?
>
> This is a very good question, and I think there's no clear-cut
> answer to it. When Debian and its Social Contract [0] were conceived,
> the focus was more on giving end users power through free software.
>
> Nowadays free software has "won" (of sorts), but the lines of
> conflict have shifted to a more subtle "place". Most of the software
> a Facebook user is in contact with is somehow "free". Heck, FB is
> one important contributor to the Linux kernel. But... would you say
> a FB user controls his/her use of FB? Tough call.
>
> To illustrate the point you made a bit better, I've seen Google
> beacons embedded in the Javascript included in free packages[1].
>
> Free but... privacy respecting? Up to debate.

I'm not a maintainer, just a user.

And a instance of the above should result in the instant moving of that 
package into the non-free category. And put a link to a readme 
explaining why its contamination by such tracking code has caused its 
status to be changed, and moved, in the former packages location. Only 
by pointing it out to the potential user, will such code eventually be 
removed.  I think debian needs to make that an upfront declaration and 
enforce it.

Any "hardware" surveys, which seem to be more invasive than ever these 
days, should pop up a requester for some sort of plainly stated 
permission before the results are sent "home". Any form of no should 
result in sending that data to /dev/null.

> You can help making Debian better by trying to find such things
> and reporting them as bugs. I think most Debian maintainers would
> agree that those go against the spirit of the Social Contract [0].

Yes, absolutely. I do not think debian could be said to have been harmed 
by such an action a year later.

> Cheers
> [0] https://www.debian.org/social_contract
>
> [1] In one case, a web app testing package, there was even a
>comment in there "please, leave this in, since that's how
>we make money", so the inclusion was not an accident. In
>the other case, it was in a Debian package -- this one has
>disappeared since, otherwise I'd have filed a bug report.
>
> -- tomás


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: Privacy policy of packages/softwares installed in Debian

[Jean-Philippe MENGUAL]

Hi,

Do you know wether FSF or OSI has some tmplate, just like licnese 
examples, for such thing?


With a tmplate, maybe Debian might accept to ship it to the packages 
like thy include COPYRIGHT, or displaying a screen to mention privacy 
policy.


One thing seems sure, Debian will never have a privacy policy, I think, 
but maaybe may request any package (or some packages) to include a 
PRIVACY file. Should require to change the Debian maintainer and dev policy.


Regards


Regards,


Jean-Philippe MENGUAL

Le 10/06/2019 à 09:08, npdflr a écrit :

Thanks Jean for your reply.

Non-free packages should definitely be checked with their privacy 
policy. But what about free packages?


The license for the Go programming language is 
https://golang.org/LICENSE which is free but the privacy policy is 
invasive https://policies.google.com/privacy?hl=en
(Note: it also has a patent file with some restrictions which can make 
the package non-free perhaps, would give more details if required)


Free networking applications like browsers, p2p applications etc would 
definitely require internet but other free apps also connect with the 
internet automatically when starting for the first time (Eg: aseprite, 
libreoffice) or when checking for updates. One can know this via an 
application-based firewall.


Free packages are available via main repositories (through terminal apt 
commands or a package manager) and also via other ways like websites, 
terminal commands like wget, curl etc, offline archive files etc.


Would you say that all free packages via main repositories and via other 
ways (after checking their license to be DFSG-compliant) can be safely 
be allowed to connect to the internet?


Thanks.


 On Sun, 09 Jun 2019 05:49:01 -0700 *Jean-Philippe MENGUAL 
mailto:jpmeng...@debian.org>>* wrote 


Hi,

Privacy policy makes sense for software you quote, eithr because
they are closd-code, or because thy are in the cloud and users send
data to servers, so it is important to know what do this data once sent.

Debian provides free software and does not support non-free one even
if they exist in the Debian infra. They provide tools to be
installed on your computer. So when you install a program in Debian,
you can check the code, but more important, you dont send data to an
external source.

Then I dont think Debian needs a privacy policy. Neither Debian, nor
the packages themselves collect the user data. And it would be a
problem to do this, from the socail contract.

I think we can consider having a thought about it if some program
collects data. For a non free program, this should be in its licene
or on th websie of its provider.

Regards




Jean-Philippe MENGUAL

Le 08/06/2019 à 20:02, npdflr a écrit :


Hello,
How can one check the privacy policy for the packages/softwares
(which can be free or non-free) installed in Debian?

If one is downloading and installing a package from a website
then he/she can check the privacy policy link on that website.
Example:
-- Skype (https://www.skype.com/en/get-skype/) which has privacy
policy: https://privacy.microsoft.com/en-US/privacystatement
-- Go programming language (https://golang.org/) which has
privacy policy: https://policies.google.com/privacy?hl=en

But if one is downloading a package (which may also install
dependency packages) via terminal or synaptic package manager
then how can one check the privacy policy of that package?

Thank you.

Re: What is agetty, and why can't it be stopped?

[Gene Heskett]

On Monday 10 June 2019 04:46:33 am Curt wrote:

> On 2019-06-06, Gene Heskett  wrote:
> > What do I do next to get rid of this nearly invisible agetty gizmo
> > once this machine is booted?  It might be handy if this machine is
> > truly hung, but I can count those instances on one hand with fingers
> > left over in the 21 years I have been a linux only house.
>
> Maybe
>
> sudo systemctl stop serial-getty@ttyS0.service
>
> if you haven't already tried it.

No, after a reboot, I don't need to.

minicom is working, sorta.  Theres enough diffs in the protocol to 
call "working" by a rather fuzzy definition.  But at least /dev/ttyS0 is 
now available for MY use. That was the squawk. I still have not found 
where the previous boot, to the same kernel/etc might have decided to 
grab /dev/ttyS0 for its own use. The previous boot did send 7 or 8 bytes 
of data that was just random line noise to the legacy machine on the 
receiving end that cable. Other than that, I'm still clueless.

If I were to file a bug, it would be against java's current (stretch) 
jre.  It has no backward compatibility with the wheezy version and has 
broken another utility we use so badly that the majority of it has now 
been re-written in pypy.  So we at least have the function, if not 
the "purty" we had with the wheezy version of the jre. The purty will be 
improved I am sure. The pypy effort is quite young yet.

>
> > Thanks all;
> >
> > Cheers, Gene Heskett


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: Severe vulnerability in Exim 4.87 through 4.91

[Greg Wooledge]

On Sat, Jun 08, 2019 at 04:50:06PM -, Curt wrote:
> https://lwn.net/Articles/790553/
> 
> I was actually going to point to another article on the subject, but as
> it revealed the exact modus operandi for the (local) exploit (which is
> trivial to an extreme) I thought better of it.

https://www.debian.org/security/2019/dsa-4456

https://security-tracker.debian.org/tracker/CVE-2019-10149

Re: Severe vulnerability in Exim 4.87 through 4.91

[Curt]

On 2019-06-10, Greg Wooledge  wrote:
> On Sat, Jun 08, 2019 at 04:50:06PM -, Curt wrote:
>> https://lwn.net/Articles/790553/
>> 
>> I was actually going to point to another article on the subject, but as
>> it revealed the exact modus operandi for the (local) exploit (which is
>> trivial to an extreme) I thought better of it.
>
> https://www.debian.org/security/2019/dsa-4456
>
> https://security-tracker.debian.org/tracker/CVE-2019-10149
>
>

Okay, thank you, so fixed in Stretch with the package update to 4.89-2+deb9u4
a few days ago (other releases not vulnerable).


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: What is agetty, and why can't it be stopped?

[Curt]

On 2019-06-10, Gene Heskett  wrote:
>>
>> Maybe
>>
>> sudo systemctl stop serial-getty@ttyS0.service
>>
>> if you haven't already tried it.
>
> No, after a reboot, I don't need to.
>
> minicom is working, sorta.  Theres enough diffs in the protocol to 
> call "working" by a rather fuzzy definition.  But at least /dev/ttyS0 is 
> now available for MY use. That was the squawk. I still have not found 
> where the previous boot, to the same kernel/etc might have decided to 
> grab /dev/ttyS0 for its own use. The previous boot did send 7 or 8 bytes 
> of data that was just random line noise to the legacy machine on the 
> receiving end that cable. Other than that, I'm still clueless.

Well, Michael Stone's guess was a good one (though, apparently, wrong).

Of course, you don't show any logs so it's anybody's guess.

Here's another: modemmanager probing ttyS0 trying to identify a modem.

Probably not, though. Anyway, it's working, which is enough for some of
us in this crazy old world.

> If I were to file a bug, it would be against java's current (stretch) 
> jre.  It has no backward compatibility with the wheezy version and has 
> broken another utility we use so badly that the majority of it has now 
> been re-written in pypy.  So we at least have the function, if not 
> the "purty" we had with the wheezy version of the jre. The purty will be 
> improved I am sure. The pypy effort is quite young yet.
>
>>
>> > Thanks all;
>> >
>> > Cheers, Gene Heskett
>
>
> Cheers, Gene Heskett


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Dual Boot Two Debian Versions

[Stephen P. Molnar]

My Debian platform has four drives:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
??sda1 8:1 0 457.9G 0 part /
??sda2 8:2 0 1K 0 part
??sda5 8:5 0 7.9G 0 part [SWAP]
sdb 8:16 0 1.8T 0 disk
??sdb1 8:17 0 1.8T 0 part /sdb1
??sdb2 8:18 0 1K 0 part
??sdb5 8:21 0 7.9G 0 part
sdc 8:32 0 465.8G 0 disk
??sdc1 8:33 0 465.8G 0 part /sdc1
sr0 11:0 1 2K 0 rom

sda is a 500 GB SSD, currently the boot drive, running Stretch
sdb is a 2 TB mechanical hard drive, used for storage and
sbc is a 500 GD SSD, containg a number of computational chemistry 
applications that I use for my research.


I am planning on adding a 1 TB SSD to the system to be dedicated to 
Buster (currently Testing).


I know that if I select the new drive (for the purpose of this note, 
sdd) for Buster during the installation process from the iso DVD, that 
Buster will be installed on sdd and grub will show that as the boot 
drive. There would also be an entry in grub for Stretch on sda.


Herein lies the problem, sda is the boot drive, but Buster would not be 
a grub entry. Whenever I reboot the system, Buster will be hidden. A 
workaround would be to hit the appropriate key during the initial stages 
of the boot process to open the Bios and then manually select Buster to 
boot.


Couple of questions:

Will installing Buster on sdd do anything to make Stretch unbootable?
Is there a way that I can add Buster to the Stretch Grub Boot Screen? 
Perhaps grub-customizer?


I know this is rather convoluted, but it is essential, for non technical 
reasons to keep Stretch available while I am using Buster.


Thanks in advance.

--
Stephen P. Molnar, Ph.D.  Life is a fuzzy set
www.molecular-modeling.net Stochastic and multivariate
(614)312-7528(c)
Skype:  smolnar1

Re: What is agetty, and why can't it be stopped?

[Michael Stone]

On Mon, Jun 10, 2019 at 01:44:36PM -, Curt wrote:

Well, Michael Stone's guess was a good one (though, apparently, wrong).


The one thing I've learned is that Gene does weird things to his systems 
and has issues that nobody else has. I'll throw out a guess, but I won't 
waste a lot of time on it. It is certain that systemd doesn't generally 
activate a getty on a serial port, so something's turning it on. But, 
playing 20,000 questions and getting straight answers to 10,000 of them 
after reading 10,000 pages of anecdotes just isn't fun for most people, 
so we'll probably just leave this in the "undocumented weirdness" pile 
and move on.



Of course, you don't show any logs so it's anybody's guess.


Bingo.

Re: Privacy policy of packages/softwares installed in Debian

[tomas]

On Mon, Jun 10, 2019 at 06:43:17AM -0400, Gene Heskett wrote:

[...]

> I'm not a maintainer, just a user.
> 
> And a instance of the above should result in the instant moving of that 
> package into the non-free category. And put a link to a readme 
> explaining why its contamination by such tracking code has caused its 
> status to be changed, and moved, in the former packages location.

Normally a maintainer just removes such a nasty -- that's what the
Debian-specific patches are for. But first you have to find it.

Just imagine yourself as a maintainer of (say) 5 packages, 500k lines
of code each. In your free time. Getting an update every 2 months each.

Do you go with a fine comb over each and every changed line of code
each time?

That's why our maintainers need help. Just saying "Debian Should" is
not enough help :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: What is agetty, and why can't it be stopped?

[Gene Heskett]

On Monday 10 June 2019 09:44:36 am Curt wrote:

> On 2019-06-10, Gene Heskett  wrote:
> >> Maybe
> >>
> >> sudo systemctl stop serial-getty@ttyS0.service
> >>
> >> if you haven't already tried it.
> >
> > No, after a reboot, I don't need to.
> >
> > minicom is working, sorta.  Theres enough diffs in the protocol to
> > call "working" by a rather fuzzy definition.  But at least
> > /dev/ttyS0 is now available for MY use. That was the squawk. I still
> > have not found where the previous boot, to the same kernel/etc might
> > have decided to grab /dev/ttyS0 for its own use. The previous boot
> > did send 7 or 8 bytes of data that was just random line noise to the
> > legacy machine on the receiving end that cable. Other than that, I'm
> > still clueless.
>
> Well, Michael Stone's guess was a good one (though, apparently,
> wrong).
>
> Of course, you don't show any logs so it's anybody's guess.
>
logs are a mess. Everything I ran for email support on wheezy, that kept 
its own logs, is now spamming syslog to the extent that in an hour, any 
interesting log events have scrolled well of the 10,000 line buffer I 
give each shell. Finding anything in that mess even with grep is almost 
impossible, because you can highlight it to do a copy/paste to an email, 
and theres nothing in the buffer after switching windows and positioning 
the cursor for the paste, its already scrolled off screen, which cancels 
the highlight.

Trying to move spamd's log is hopeless because now they have no 
permissions to use /var/log.  Thats such a pain in the ass to make it 
work that I gave it up on wheezy and made a log dir in my home dir and 
fixed logrotate to service them there. What the hell, I thought /var/log 
was where to find/keep logs, but when only root can use it, its the same 
as the belly appendages on a boar hog. Useless. Just because of someones 
paranoia.
 
> Here's another: modemmanager probing ttyS0 trying to identify a modem.
>
> Probably not, though. Anyway, it's working, which is enough for some
> of us in this crazy old world.

> > If I were to file a bug, it would be against java's current
> > (stretch) jre.  It has no backward compatibility with the wheezy
> > version and has broken another utility we use so badly that the
> > majority of it has now been re-written in pypy.  So we at least have
> > the function, if not the "purty" we had with the wheezy version of
> > the jre. The purty will be improved I am sure. The pypy effort is
> > quite young yet.
> >
> >> > Thanks all;
> >> >
> >> > Cheers, Gene Heskett
> >
> > Cheers, Gene Heskett

Sorry for the bad mood. I can barely walk from the back pain. I've 2 
riding mowers all apart in the driveway, 2 crushed disks in my back 
making me miserable after 2 days of working on it, and still much of a 
day yet getting a rider back in a state I can climb on, twist the key 
and mow.  And its 3+ feet deep in places in the back yard.  That or 
$1800 to get far enough up the quality ladder to get rid of the kawasaki 
or briggs and scrapiron motors. Both are problem children.  Kohler 
engines just work.  Honda engines just work. And the guy who could pick 
up 200 lbs and walk it all over town? At 84 he doesn't live here 
anymore.



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: Privacy policy of packages/softwares installed in Debian

[Gene Heskett]

On Monday 10 June 2019 11:17:04 am to...@tuxteam.de wrote:

> On Mon, Jun 10, 2019 at 06:43:17AM -0400, Gene Heskett wrote:
>
> [...]
>
> > I'm not a maintainer, just a user.
> >
> > And a instance of the above should result in the instant moving of
> > that package into the non-free category. And put a link to a readme
> > explaining why its contamination by such tracking code has caused
> > its status to be changed, and moved, in the former packages
> > location.
>
> Normally a maintainer just removes such a nasty -- that's what the
> Debian-specific patches are for. But first you have to find it.
>
> Just imagine yourself as a maintainer of (say) 5 packages, 500k lines
> of code each. In your free time. Getting an update every 2 months
> each.
>
> Do you go with a fine comb over each and every changed line of code
> each time?
>
> That's why our maintainers need help. Just saying "Debian Should" is
> not enough help :-)
>
All of that I'm well aware of Tomas. So yes "should" is a bit stronger 
sounding than I intended.  But at my thinkers age, I'd like to think I 
have sense enough left to know my limits.  So I ask.  I am behind the 
curve of any modern language, even bash scripts I wrote 10 years ago can 
be a puzzle when they miss-fire until I've mentally stepped thru them 
several times. Its even personally embarrassing if when I find the why, 
and wonder WIH did I do it that way?

> Cheers
> -- t


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: Privacy policy of packages/softwares installed in Debian

[John Hasler]

Gene writes:
> All of that I'm well aware of Tomas. So yes "should" is a bit stronger
> sounding than I intended.  But at my thinkers age, I'd like to think I
> have sense enough left to know my limits.  So I ask.  I am behind the
> curve of any modern language, even bash scripts I wrote 10 years ago
> can be a puzzle when they miss-fire until I've mentally stepped thru
> them several times. Its even personally embarrassing if when I find
> the why, and wonder WIH did I do it that way?

Programming adage: Never make your code so clever that you can just
barely understand it yourself because *you* will have to understand it
in the future and you won't be this clever then.

On the other hand "What idiot designed this?  Oh.  It was me." is an
ordinary engineering experience.

You can help the maintainers by running Unstable or Testing and filing
bug reports.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Privacy policy of packages/softwares installed in Debian

[Gene Heskett]

On Monday 10 June 2019 01:00:58 pm John Hasler wrote:

> Gene writes:
> > All of that I'm well aware of Tomas. So yes "should" is a bit
> > stronger sounding than I intended.  But at my thinkers age, I'd like
> > to think I have sense enough left to know my limits.  So I ask.  I
> > am behind the curve of any modern language, even bash scripts I
> > wrote 10 years ago can be a puzzle when they miss-fire until I've
> > mentally stepped thru them several times. Its even personally
> > embarrassing if when I find the why, and wonder WIH did I do it that
> > way?
>
> Programming adage: Never make your code so clever that you can just
> barely understand it yourself because *you* will have to understand it
> in the future and you won't be this clever then.
>
Chuckle.  Yessir. I used to do my coding in assembler, and later in C but 
that C was first edition, without the advanced bit twiddling since that 
target cpu's didn't have a barrel shifter. My targets started out with 
the rca 1802 in '78. Might have included the TI-9900 but the entry price 
was above my pay grade, so the majority of my code output ran on a 6809 
or 6309 & still does. The 6x09's with PIC were a breath of fresh air, 
and cleared the way for a unix-like os called os9. When the 6309 was 
discovered I volunteered to rewrite a portion of that os to make it run 
faster. But all that was 40 to 30 years ago.

> On the other hand "What idiot designed this?  Oh.  It was me." is an
> ordinary engineering experience.

Head slappers, John.  Feels so good when you stop :)

> You can help the maintainers by running Unstable or Testing and filing
> bug reports.

Is there a URL to aid that upgrade?  Or is it a start with a new drive & 
iso image? I'm in favor of operational continuity, if it can be had.

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: Privacy policy of packages/softwares installed in Debian

[Greg Wooledge]

On Mon, Jun 10, 2019 at 01:33:14PM -0400, Gene Heskett wrote:
> > You can help the maintainers by running Unstable or Testing and filing
> > bug reports.
> 
> Is there a URL to aid that upgrade?  Or is it a start with a new drive & 
> iso image? I'm in favor of operational continuity, if it can be had.

Most of the time, the only supported method is to install (or upgrade to)
stable, and then upgrade to testing or unstable.  The steps for that
are typically "edit sources.list, and then run apt update, and then run
apt full-upgrade", although the exact state of testing or unstable at any
given moment may require additional steps.

Right now, as we approach a new release, there may be an option to attempt
a direct installation of buster (currently testing) using a buster install
image.  Doing so serves as an additional test of the buster installer,
which is far more likely to have show-stopping bugs than buster itself is.

https://wiki.debian.org/DebianTesting

Re: Dual Boot Two Debian Versions

[Pascal Hambourg]

Le 10/06/2019 à 16:04, Stephen P. Molnar a écrit :


sda is a 500 GB SSD, currently the boot drive, running Stretch

(...)
I am planning on adding a 1 TB SSD to the system to be dedicated to 
Buster (currently Testing).


I know that if I select the new drive (for the purpose of this note, 
sdd) for Buster during the installation process from the iso DVD, that 
Buster will be installed on sdd and grub will show that as the boot 
drive.


Not necessarily. You can choose to install GRUB on any drive. But I 
would not recommend to install in any other drive than Buster's.



Will installing Buster on sdd do anything to make Stretch unbootable?


Yes, if you choose to install GRUB on Stretch's drive (sda).

Is there a way that I can add Buster to the Stretch Grub Boot Screen? 


Of course. Just boot Stretch, make sure os-prober is installed and 
GRUB_DISABLE_OS_PROBER is not set to "true" in /etc/default/grub, and 
run update-grub.


This method is easy but has the disadvantage that Stretch's GRUB menu is 
not automatically updated after Buster's kernel changes. Alternatively 
you can add a custom menu entry in Stretch's GRUB config to chainload 
Buster's GRUB or load Buster's GRUB config.

Preseed file and hostname not used on installed system

[john doe]

Hi, I'm installing Debian Stretch using a preseed file, the preseed file
is common for multiple hosts with the exception of the hostname.

boot: auto hostname=try domain=example.com ...
url=tftp://hostname/preseed.cfg

The host name specified is not used when Debian is installed, it is
always set to 'bad'.

I understand the limitations but what is the proper way to specify the
desired hostname or are workarounds (1) the way to go?

Any help/hints is appriciated.


https://unix.stackexchange.com/questions/106614/preseed-cfg-ignoring-hostname-setting


--
John Doe

konquerer access to Stretch with fish or sftp not working

[Thomas]

Hello,
I have problems to access an Stretch debian Server with 
fish://root@192.168.1.20 or sftp://root@192.168.1.20.
I is not working.
Access to other workings are OK.
Thanks Thomas

Re: konquerer access to Stretch with fish or sftp not working

[Étienne Mollier]

Thomas, on 2019-06-10 :
> I have problems to access an Stretch debian Server with
> fish://root@192.168.1.20 or sftp://root@192.168.1.20.
> I is not working.
> Access to other workings are OK.

Good Day Thomas,

Does a simple SFTP session work on command line?

$ sftp root@192.128.1.20

If not while using the command line ssh is okay; then it is
quite possible that you have some command in the .bashrc of your
remote root account that is echoing some message into stdout.
Without having an explanation for this, I have seen this
behaviour consistently breaking the SFTP subsystem.  Maybe you
are encountering the same.

Otherwise, it would be nice to get more details of what is
happening, using the verbose flag of the command line, to see
when, and hopefully why, it breaks:

$ sftp -v root@192.128.1.20

Kind Regards,
-- 
Étienne Mollier 

logging for complicated setups, (was: What is agetty, and why can't it be stopped?)

[bw]

In-Reply-To: <201906101154.09137.ghesk...@shentel.net>
[snip]
>What the hell, I thought /var/log 
>was where to find/keep logs, but when only root can use it, its the same 
>as the belly appendages on a boar hog. Useless. Just because of someones 
>paranoia.
...

I'd have to disagree with this Gene.  There is quite a lot of information 
in /var/log that might be a good idea to keep private on a multiuser 
system, which gnu/linux does a good job at (from what I read, I have never 
been admin on one) and on a single user system, it's plain easy to either 
get to these logs as root, or arrange to have your user able to access 
them.

Now I am not a 20+ yr user like you, but I do agree it is more difficult 
to understand logs than it was when I was a baby.  I'm younger than you, 
but going to be as old as you, so let me know if you find any good 
solution to how much info of what type should be logged, and how to find 
things that are logged?

>From what I understand and have practiced, it's better to log more, use 
tools to filter/sort more efficiently.

Thanks,
bw 

Scratch that Actually Gene...

[bw]

After seeing the struggles you are going thru, and since I see the 
incredible effort people make to help you...

IF it was me, I would probably make one good post describing every 
machine, keyboard, terminal, monitor, device, hard drive, modem, tablet, 
laptop, cnc, or cordless drill you are using on your setup.  And every 
time I asked a question I would include a link to this information.

Really, there are some brilliant people on this list, don't remain stunted 
from lack of gaining their experience?  They can't help if you only let 
them see the local issue, consider showing the whole topography?

hang in there.

Re: openjdk-8-jre for buster

[Richard Hector]

On 8/06/19 3:16 AM, Nicholas Geovanis wrote:

> On Fri, Jun 7, 2019 at 5:38 AM Jonathan Dowland  > wrote:
>
>
> You're quite right. I frequently mix up stretch and squeeze: the
> forthcoming
> run of Buster, Bullseye and Bookworm will be far more confusing
> for me :-(
>
>
> Perhaps it is time to switch to a different movie franchise.
> LOTR?
> How could you run out of names? Just pick a language :-)

So we'll need support for runes etc just for the name of the distro? :-)

Richard

Re: Dual Boot Two Debian Versions

[David Christensen]

On 6/10/19 7:04 AM, Stephen P. Molnar wrote:

My Debian platform has four drives:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
??sda1 8:1 0 457.9G 0 part /
??sda2 8:2 0 1K 0 part
??sda5 8:5 0 7.9G 0 part [SWAP]
sdb 8:16 0 1.8T 0 disk
??sdb1 8:17 0 1.8T 0 part /sdb1
??sdb2 8:18 0 1K 0 part
??sdb5 8:21 0 7.9G 0 part
sdc 8:32 0 465.8G 0 disk
??sdc1 8:33 0 465.8G 0 part /sdc1
sr0 11:0 1 2K 0 rom

sda is a 500 GB SSD, currently the boot drive, running Stretch
sdb is a 2 TB mechanical hard drive, used for storage and
sbc is a 500 GD SSD, containg a number of computational chemistry 
applications that I use for my research.


I am planning on adding a 1 TB SSD to the system to be dedicated to 
Buster (currently Testing).


I know that if I select the new drive (for the purpose of this note, 
sdd) for Buster during the installation process from the iso DVD, that 
Buster will be installed on sdd and grub will show that as the boot 
drive. There would also be an entry in grub for Stretch on sda.


Herein lies the problem, sda is the boot drive, but Buster would not be 
a grub entry. Whenever I reboot the system, Buster will be hidden. A 
workaround would be to hit the appropriate key during the initial stages 
of the boot process to open the Bios and then manually select Buster to 
boot.


Couple of questions:

Will installing Buster on sdd do anything to make Stretch unbootable?
Is there a way that I can add Buster to the Stretch Grub Boot Screen? 
Perhaps grub-customizer?


I know this is rather convoluted, but it is essential, for non technical 
reasons to keep Stretch available while I am using Buster.


Thanks in advance.


HDD's, SSD's, USB flash drives, optical drives, etc., fail.  I have 
dealt with more than a few lately.  It sounds like you are getting the 
point where you should consider redundancy.



I prefer small (16+ GB), single SSD's or USB flash drives for system 
disks.  Redundancy consists of periodic and on-demand images, daily 
backups, and keeping configuration file changes in a version control system.



I partition my Debian and FreeBSD system drives with 1 GB boot, 1 GB 
swap, and 10 to 12 GB root:


1.  I can use 16+ GB USB flash drives, HDD's, and SSD's for system 
images.  All are readily available and inexpensive.


2.  One device is easier to administer than two devices in a mirror, and 
only requires one bay and one port.


3.  I use lowest-common denominator partitioning schemes (MBR) and boot 
loaders (BIOS), so that any image on any device can boot in any machine.


4.  The small size makes it practical to take images on a regular basis, 
and to retain a few copies for each system.



I use large, enterprise HDD's in a mirror for data.  (Unused/ old stock 
enterprise SATA disks are surprisingly affordable.)



For your situation, I would forget the 1 TB SSD, get another 2 TB HDD, 
and rebuild/ migrate into one or two computers:


1.  Alternative #1 -- one computer:

a.  Install Stretch onto a high-quality 16 GB USB 3.0 flash drive. 
Install virtual machine software.


b.  Set up the two 500 GB SSD's as a mirror.  Build a Stretch VM. 
Build a Buster VM.  Create a directory that is shared into both VM's. 
Install the chemistry software there.


c.  Set up the two 2 TB HDD's as a mirror.  Create a directory that 
is shared into both VM's.  Install data there.


2.  Alternatively #2 -- two computers:

a.  Workstation with 16 GB USB flash drive, two 500 GB SSD mirror, 
Stretch VM, Buster VM, and chemistry software, as above.


b.  File server with Stretch on 16 GB USB flash drive and data on 
two 2 TB mirror.  Share data via Samba.



Make sure you have several large HDD's for backups.  I have three 
desktop 3 TB drives in a rotation scheme for backups, archives, and 
images.  Docking bays and drive drawers are especially useful:



https://www.startech.com/HDD/Mobile-Racks/Black-Serial-ATA-Drive-Drawer-with-Shock-Absorbers-Professional-Series~DRW115SATBK


David

Re: How to set access permissions to protect a database file?

[David Christensen]

On 6/9/19 2:32 PM, Markos wrote:

Many thanks to Mick, David and Joe,

To guarantee "some" protection to the file containing the database I 
decided to use the following strategy:


I created, as root, the directory /home/reading_room

And activated the "sticky bit" of the reading_room directory with the 
command:


chmod +t /home/reading_room/

And transferred, the files to the new directory with the following 
access permissions:

reading_room.tcl  rwxr--r-x  (owner markos)

reading_room.db rw-r--rw- (owner markos)

This way other users can run the reading_room.tcl program but can't  but 
not edit.


And can't delete the files (.tcl or .db)

Trying to protect against Murphy, but not Machiavelli.

Thank you,
Markos


I created a test setup similar to your solution:

2019-06-10 08:23:27 dpchrist@tinkywinky ~
$ cat /etc/debian_version ; uname -a
9.9
Linux tinkywinky 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 
(2019-05-13) x86_64 GNU/Linux


2019-06-10 08:14:52 dpchrist@tinkywinky ~
$ mkdir foo

2019-06-10 08:16:33 dpchrist@tinkywinky ~
$ chmod +t foo

2019-06-10 08:29:54 dpchrist@tinkywinky ~
$ echo 'echo "hello" >> /home/dpchrist/foo/hello.txt' > foo/hello.sh

2019-06-10 08:30:08 dpchrist@tinkywinky ~
$ chmod 0745 foo/hello.sh

2019-06-10 08:30:14 dpchrist@tinkywinky ~
$ echo 'initial contents' > foo/hello.txt

2019-06-10 08:30:40 dpchrist@tinkywinky ~
$ chmod 0646 foo/hello.txt

2019-06-10 08:30:53 dpchrist@tinkywinky ~
$ ls -l foo/hello.*
-rwxr--r-x 1 dpchrist dpchrist 45 Jun 10 08:30 foo/hello.sh
-rw-r--rw- 1 dpchrist dpchrist 17 Jun 10 08:30 foo/hello.txt

2019-06-10 08:31:29 dpchrist@tinkywinky ~
$ cat foo/hello.sh
echo "hello" >> /home/dpchrist/foo/hello.txt

2019-06-10 08:31:34 dpchrist@tinkywinky ~
$ cat foo/hello.txt
initial contents


If I test it as another user:

tinkywinky@tinkywinky:~$ ls -la /home/dpchrist/foo
total 8
drwxr-xr-t 1 dpchrist dpchrist   34 Jun 10 08:29 .
drwxr-xr-x 1 dpchrist dpchrist 1694 Jun 10 08:20 ..
-rwxr--r-x 1 dpchrist dpchrist   45 Jun 10 08:30 hello.sh
-rw-r--rw- 1 dpchrist dpchrist   23 Jun 10 08:39 hello.txt

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.sh
echo "hello" >> /home/dpchrist/foo/hello.txt

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.txt
initial contents

So, other users:

- Can see the script file system entry.

- Can see the data file file system entry.

- Can see the contents of the script (!).

- Can see the contents of the data file (!).


Continue testing:

tinkywinky@tinkywinky:~$ /bin/sh /home/dpchrist/foo/hello.sh

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.txt
initial contents
hello

So:

- Other users can run the script.

- The script can write to the data file.


Continue testing:

tinkywinky@tinkywinky:~$ rm -rf /home/dpchrist/foo
rm: cannot remove '/home/dpchrist/foo/hello.sh': Permission denied
rm: cannot remove '/home/dpchrist/foo/hello.txt': Permission denied

So, other users:

- Cannot delete the script.

- Cannot delete the data file.


Continue testing:

tinkywinky@tinkywinky:~$ echo "blah" > /home/dpchrist/foo/hello.sh
-bash: /home/dpchrist/foo/hello.sh: Permission denied

tinkywinky@tinkywinky:~$ echo "blah" > /home/dpchrist/foo/hello.txt

tinkywinky@tinkywinky:~$ cat /home/dpchrist/foo/hello.txt
blah

So, other users:

- Cannot overwrite the script.

- Can overwrite the data file (!).


Continue testing:

tinkywinky@tinkywinky:~$ vi /home/dpchrist/foo/hello.sh
echo "pwn3d" >> /home/dpchrist/foo/hello.txt
:w
E45: 'readonly' option is set (add ! to override)
:w!
"/home/dpchrist/foo/hello.sh" E212: Can't open file for writing
Press ENTER or type command to continue
:q!

tinkywinky@tinkywinky:~$ vi /home/dpchrist/foo/hello.txt
pwn3d
:w
"/home/dpchrist/foo/hello.txt" 1 line, 6 characters written
:q

So, other users:

- Cannot edit the script.

- Can edit the data file (!).


You have found an interesting combination of mode bits and multi-user 
behavior.  I can see how that could work in a "friendly" environment, 
where you are protecting against mistakes rather than protecting against 
attacks.



You will want to back up the data file frequently.


It has been many years since I played with the special mode bits.  This 
article is a decent refresher:


https://linuxconfig.org/how-to-use-special-permissions-the-setuid-setgid-and-sticky-bits


I found another article that describes how to wrap a script with a C 
program, so that the set UID and set GID bits will work.


https://engineering.purdue.edu/ECN/Support/KB/Docs/HowToSUIDSGIDscripts


If you created a restricted user account just for the app and data, 
created an executable wrapper, and adjusted the mode bits, I believe you 
could prevent users from seeing the contents of the script, seeing the 
contents of the database, overwriting the database, and editing the 
database.



David