Re: Mailing-list configuration

[Nicolas George]

Le nonidi 29 prairial, an CCXXIV, Andrew McGlashan a écrit :
> If you see no reply-to header, then only do reply to list as already
> instructed with L for mutt, which I don't use.
> 
> Always do reply to list, it's simple.  IF someone says they are not
> subscribed, please CC me, then take that instruction as explicit from
> the email that you are replying to ... again, simple.
> 
> I used to do reply-all almost always, now I am more careful due to
> requests from others being annoyed.  Reply To LIST works perfectly well
> for most people and the odd miss due to an extra instruction on a per
> email basis is a different problem.

I choose this mail to make my global answer because it raises the right
points. But this is a reply to all the mails that argue similar positions.

Yes, getting it right is simple. Once. But you are not seeing the big
picture here. We are not talking about one mail, we are talking about a lot
of mails, from several mailing-lists with different attitudes, and also from
private discussions, including discussions with people who are usually found
on mailing-lists (and that therefore seem at first glance to be on the
list). People need get the recipient list right every single time. Even when
paying attention, mistakes happen. The more rules there are to follow
manually, the more mistakes happen.

The whole point of using computers is to automate the stupid tedious tasks
in order to save time for the humans for the interesting creative tasks.
Choosing the list of recipient can be automated, most of the time. You
actually have to wonder why people are so adamant at being good at the
tedious automatable tasks; maybe they need to hide how bad they are at the
creative tasks: "I have nothing interesting to say, but at least I say it to
exactly the right people".

  Conclusion #1: selecting the list of recipients must be automated as much
  as possible.

  Claim (proven later): automation is possible.

The efficiency of automation can be evaluated objectively, it is called the
entropy. The result, as expected, is that the most efficient case is when
there is a single button that does the work almost every time. The worst
case is when there are several buttons that are used all roughly the same
number of times.

With that in mind, you realize that the reply-to-list feature is bad UI
design: it moves away from the one-button-does-it-all case (entropy = ~0)
towards two-buttons-half-the-time (entropy = ~0.7). This is painfully
obvious if you realize that the reply-to-list feature just refuses (at least
the Mutt implementation) to work for private discussions.

  Conclusion #2: the reply-to-list is not good automation.

Now, let us examine the consequences of mistakes when selecting the CCs. As
often in this kind of cases, there are two possible mistakes: forgetting a
wanted CC or adding an unwanted CC. An unwanted CC is a minor annoyance for
the recipient. It is not even spam: they wanted to see the contents of the
mail, only not directly in their mailbox.

A forgotten CC is a much more severe issue: it is breaking the thread for
that particular recipient. Even more so, since people who reply to the mail
with the forgotten CC will not have the CC either: all the subsequent
discussion is diverted from the person who was most interested in it.

It is the same reasoning with spam filters: people usually prefer seeing a
few spams in their inbox than missing a legitimate, possibly urgent, mail.

  Conclusion #3: when in doubt, rules and automation must err in favour of
  CCs.

With that in mind, let us examine the "code of conduct":

# When replying to messages on the mailing list, do not send a carbon copy
# (CC) to the original poster unless they explicitly request to be copied.

How does that work, exactly? How is the "original poster" supposed to
express that request? Once? Consider people who are involved in half a dozen
threads spanning over more than a week. Are they supposed to remember every
request of CC by everybody in the thread? That can not work. Or should the
request be made on every single mail? People will forget it, and people who
reply will forget to take it into account. All these honest mistakes result
in broken threads.

It does not work. Not really, not with the volume of a Debian mailing-list,
and not with the volume of other mail that someone who can make the most
useful contributions (someone involved in fixing bugs or developing other
Libre software projects) handles. Automation is the only way to go.

  Conclusion #4: this clause of the "code of conduct" does not work and
  therefore must be ignored.

How should it work. It is not that complicated. Consider you want to reply
to one mail with a valid good list of recipients:

From: A
To: debian-user
Cc: B, C

Consider this is a normal reply (not, for example, a private reply to ask A
how they get the French Republican calendar; for the record this is achieved
with a Vim script on top of a specific 

[SOLVED (sort of)]Re: apt-get update fails with sourceforge repo

[Michael Lange]

On Tue, 14 Jun 2016 00:13:43 +0200
Michael Lange  wrote:

> Ok, looks like it's a bug in Jessie's apt version.

Just for the record, in case anyone reads this:
I filed a bug report for apt about this issue
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827365 ),
however it showed that a new feature in apt stops apt from accepting the
kind of hhtp(s) redirects sourceforge now uses. This at least explains
the initially odd observation that the sf repo still works with outdated
versions of apt.
So it looks like (at least for now) it is simply not possible to use
debian repositories hosted on sourceforge.
I added a note about this to the ticket at 
https://sourceforge.net/p/forge/site-support/12143/ , so they hopefully
will know what to do if they care to fix this.
For now obviously the best choice seems to move one's repos to a
different hosting service.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3

Re: Mailing-list configuration

[Tanstaafl]

On 6/15/2016 4:23 PM, Rodary Jacques  wrote:
> Not using any MUA, just a browser (Opera, which is BTW in the official
> Debian list: https://wiki.debian.org/WebBrowsers, non-free but I don't
> know why as it is a Mozilla clone; Mozilla isn't free

What a ridiculous claim this has always been by debianites...

But, the fact is, Debian and Mozilla have buried the hatchet, so even
Debian officially recognizes Mozilla as free.

Re: Mailing-list configuration

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 16, 2016 at 07:26:37AM -0400, Tanstaafl wrote:
> On 6/15/2016 4:23 PM, Rodary Jacques  wrote:
> > Not using any MUA, just a browser (Opera, which is BTW in the official
> > Debian list: https://wiki.debian.org/WebBrowsers, non-free but I don't
> > know why as it is a Mozilla clone; Mozilla isn't free
> 
> What a ridiculous claim this has always been by debianites...

This is an unnecessary slur. Were it not for Hanlon's razor[1], I'd even
qualify it as malicious.

The thing is that due to Mozilla's trademark policy (which in itself made
sense!), Firefox as such was incompatible with Debian's Free Software
guidelines. Tough luck.

It's of utter importance that a distribution takes its own guidelines
seriously: that's how I, as a user, can trust Debian (in this case,
for example, that I don't incur any liabilities by distributing
(a modified version of) Debian). That's why they went to the lengths
of distributing a forked version of Firefox (the source code itself
was always free!) without the trademark liability.

Of course, it's important to try to sort out things:

> But, the fact is, Debian and Mozilla have buried the hatchet, so even
> Debian officially recognizes Mozilla as free.

perhaps that's what you want to imply with "burying the hatchet".

regards

[1] https://en.wikipedia.org/wiki/Hanlon%27s_razor

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldikVEACgkQBcgs9XrR2kbhtwCfZoGt9vEMBtIJXrjD3gn5kE0j
8eIAmgL8kErfiNMqEOt2FUwBoeTTOJk0
=M6UR
-END PGP SIGNATURE-

Re: Mailing-list configuration

[Tanstaafl]

My last reply to the spammer aka 'Nicolas George'...

On 6/16/2016 5:28 AM, Nicolas George  wrote:
> With that in mind, you realize that the reply-to-list feature is bad UI
> design:

No, but I did take a minute to test and discovered my MUA of choice
(Thunderbird) does have a bug with respect to it's 'Smart Reply' button
(aka your 'one button to rule them all') that I have now filed - so at
least my interaction with a spammer was not time totally wasted.

Rather than wasting so much bandwidth trying to justify your laziness,
why didn't you just go file a bug for your chosen MUA like I did?

'Smart Reply' should honor explicit 'Reply-To' over 'Reply List':
https://bugzilla.mozilla.org/show_bug.cgi?id=1280424

Maybe you should do the same for Mutt rather than continue violating the
debian list CoC (and spamming debian list users)?

Re: Missing signatures for installer checksums

[Jude DaShiell]

maybe an easier way if Sarah has smtp working on her debian box. 
Install report-bug and run it.  If everything gets filled in correctly 
and report-bug can actually send an e-mail, the bug report will be filed 
correctly with everything debian expects.


On Wed, 15 Jun 2016, Leon.37428 wrote:


Date: Wed, 15 Jun 2016 23:36:32
From: Leon.37428 
To: debian-user@lists.debian.org
Subject: Re: Missing signatures for installer checksums
Resent-Date: Thu, 16 Jun 2016 03:36:53 + (UTC)
Resent-From: debian-user@lists.debian.org

On 06/15/2016 10:58 PM, Sarah Newman wrote:

For CDs there is the checksum file and a signature file, one example is 
https://mirrors.kernel.org/debian-cd/current/amd64/iso-cd/SHA256SUMS and
https://mirrors.kernel.org/debian-cd/current/amd64/iso-cd/SHA256SUMS.sign.

For net installers, there is a checksum file 
https://mirrors.kernel.org/debian/dists/wheezy/main/installer-amd64/current/images/SHA256SUMS
 but there
is no matching 
https://mirrors.kernel.org/debian/dists/wheezy/main/installer-amd64/current/images/SHA256SUMS.sign
 . This is also true for versions
other than wheezy.

Are the signatures somewhere else, and if not where should a bug be filed?

Thanks, Sarah



There seems to be none, oddly enough. You may want to check out this
page: https://www.debian.org/Bugs/Reporting

I think there are also mailing lists dedicated to the bug tracking for
debian. You might want to look around for those

- Leon




--

Re: Mailing-list configuration

[Tanstaafl]

On 6/16/2016 7:45 AM,  < wrote:
> On Thu, Jun 16, 2016 at 07:26:37AM -0400, Tanstaafl wrote:
>> On 6/15/2016 4:23 PM, Rodary Jacques  wrote:
>>> Mozilla isn't free

>> What a ridiculous claim this has always been by debianites...

> This is an unnecessary slur. Were it not for Hanlon's razor[1], I'd even
> qualify it as malicious.

Really? Whatever... to claim Mozilla was 'not free' based solely on the
one little issue with the trademarked logo was just plain silly.

Call it a minor issue, call it whatever you will, but to take the
extremist position that it made Mozilla 'not free' was ridiculous, and
this position was only amplified by debian zealots.

>> But, the fact is, Debian and Mozilla have buried the hatchet, so even
>> Debian officially recognizes Mozilla as free.
> 
> perhaps that's what you want to imply with "burying the hatchet".

No implication necessary, it is what Debian officially recognizes, and
speaks for itself.

Re: Mailing-list configuration

[Dan Purgert]

Nicolas George wrote:
> Now, finally, how do we achieve automation?
>
> The ideal solution would be to have a real header telling us what to do:
> "List-Reply-To: list" or "List-Reply-To: sender, list". Unfortunately, the
> people in charge of that messed it up, they invented these useless headers
> and the "list-reply-to" command instead, see conclusions #2 and #5.

Who are "the people in charge" here?  The people who write the RFCs, or
the people who follow them?

Quick search seems to indicate that RFC5322 (Oct 2008)[1] is the current
RFC detailing the formatting and use of emails (note - email in general,
I did not find one specific to mailing lists, I don't doubt that there
is one, if not several).  It does have an update (RFC6854, March 2013),
but that does not seem to be relevant in this case.

>
> But we can make it work anyway by abusing the Reply-To header.
>
> Note: this is really abusing the header; the header was not originally
> made for that and does not allow to express all the policies we could
> think of. But it works. For most mailing-lists, setting the Reply-To
> header correctly has exactly the wanted consequences. That is not
> entirely satisfactory, but it works.

I'm not entirely sure it's an "abuse", given § 3.6.2 of RFC5322:

 | [...] The originator fields also provide the information required
 | when replying to a message.  When the "Reply-To:" field is present, it
 | indicates the address(es) to which the author of the message suggests
 | that replies be sent.  In the absence of the "Reply-To:" field,
 | replies SHOULD by default be sent to the mailbox(es) specified in the
 | "From:" field unless otherwise specified by the person composing the
 | reply.

[1] https://tools.ietf.org/rfc/rfc5322.txt

> [snip]

The rest of this is opinion based on what I've seen in this thread, feel
free to skip over if if you like. Admittedly I'm coming to the party
late, and have probably missed more than a few mails (as this list tends
to break threads for some reason).

I can see both sides of the argument here, and really, it's an issue
that both sides will likely need to end up making some changes to their
workflow for.  

That being said, it seems that the majority of the friction is between
the idea that the MUA should do everything (i.e. choose 'reply to list'
as a default if it thinks there's a list) vs. the idea that the user put
a minor amount of effort into fixing their MUA to ensure it's sending to
the list in a manner that will ensure they get what they want,
regardless of the other end.  

The second option seems (from an outside perspective) to be the "better"
approach, as MUAs are not always all that good (see: webclients, etc.),
and it (more or less) ensures that you get the responses absolutely as
you want.  

In addition, I feel that both parties in the original problem
(apparently Lisi and Nicolas -- please correct me if I'm wrong) each
have some fault in the matter.  Mainly, this seems to stem from each of
you assuming that the other's MUA behaves similarly to your own, and
then perhaps having sent one (or several) mails that were viewed by the
other as inflammatory; even if you didn't necessarily mean it that way.

As I read the mails in this thread (and others throughout the list), my
impression of you two is that you're both knowledgable, and tend to know
the material you're commenting on well.  However, your main difference
seems to be that Lisi is comparatively "newer" than Nicolas, and as such
may not have been subject to the same initial first forays into the 'net
that Nicolas has been.  I could be entirely wrong though :).

What I have found - mainly in the last year to 18 months or so - is that
there is much of 'etiquitte' that has seemingly been "lost" among
people of the internet community at large.  What I mean is, back when
"the internet" was a place you could only get to via a university,
rather than paying $15 per month at home on a $200 Chromebook, it was
pretty "easy" for newcomers to be introduced to the standing etiquitte.
It's not like we get an "Internet Etiquitte" packet with our welcome
packet from the ISP.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 

Samba 4.2.10+dfsg-0+deb8u3 and group specific policies

[Virgo Pärna]

Just checking if anyone else has problems with group specific
Group Policies with Samba Active Directory domain controller with latest
samba update (from 5th of June)? 
I have one policy that is only allowed for specific computers.
Those computers are part of special groups and groups have permission
for that policy. But those computers get "Access denied" when trying to
read that policy (GPT.INI). It worked before last update.

-- 
Virgo Pärna 
virgo.pa...@mail.ee

Re: Mailing-list configuration

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 16, 2016 at 08:20:11AM -0400, Tanstaafl wrote:
[...]
> Really? Whatever... to claim Mozilla was 'not free' based solely on the
> one little issue with the trademarked logo was just plain silly.

*plonk*
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldio+cACgkQBcgs9XrR2katOwCZAdVsfjGn4enpcnYxa7oSdhES
AYgAmwX0sC2mri2u+OACPlFkaVrwTxPJ
=BURj
-END PGP SIGNATURE-

Re: How to download over https

[Thomas Schmitt]

Hi,

> There are MD5 and SHA sums in that same directory. However I can only access
> those checksums through unencrypted connections. Therefore they cannot be
> used to check against 3rd party tampering.

The chain of trust begins by the public keys as decribed at
  https://www.debian.org/CD/verify
  https://keyring.debian.org/
which you use to verify the checksum file
  
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/8.5.0-live+nonfree/amd64/iso-hybrid/SHA512SUMS
by its signature file
  
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/8.5.0-live+nonfree/amd64/iso-hybrid/SHA512SUMS.sign

Then you can use the SHA512 sum of
  debian-live-8.5.0-amd64-cinnamon-desktop+nonfree.iso
to verify the downloaded ISO image.


Currently i am riddling about the exact command to get the necessary
GPG keys. On my Debian 8 installation

  $ gpg --verify SHA512SUMS.sign SHA512SUMS

knows that Debian LiveCD 8.3 SHA512SUMS.sign was created by

  gpg: Signature made Thu 28 Jan 2016 02:07:19 AM CET using RSA key ID 6294BE9B
  gpg: Good signature from "Debian CD signing key "

So i probably got the key by
  gpg --keyserver keyring.debian.org --recv-keys 6294BE9B


Have a nice day :)

Thomas

Re: How to download over https

[Jörg-Volker Peetz]

Did you take a look here: https://www.debian.org/CD/verify , "Verifying
authenticity of Debian CDs"?

The https protocol would add quite some overhead to the download of the
iso-files which are already big by them self.

Regards,
jvp.

Re: Samba 4.2.10+dfsg-0+deb8u3 and group specific policies

[Virgo Pärna]

On Thu, 16 Jun 2016 12:58:44 + (UTC), Virgo Pärna  
wrote:
>
> Those computers are part of special groups and groups have permission
> for that policy. But those computers get "Access denied" when trying to
> read that policy (GPT.INI). It worked before last update.
>

Or maybe I'm wrong about it been about group specific policies.
Because when I removed permission for that group, then it fails with
another policy - and then it fails with another policy. 
But strange thing is, that while Windows Vista reports error,
Windows 10 succeeds.

-- 
Virgo Pärna 
virgo.pa...@mail.ee

Re: How to download over https

[Matthew Davis]

> Did you take a look here: https://www.debian.org/CD/verify , "Verifying
authenticity of Debian CDs"?

Yes I did. It's incredibly confusing. It's written with assumed knowledge that 
a lot of users don't have. There are lots of hex strings with mysterious 3 
letter abbreviations and no commands in sight. (And I don't even consider 
myself a novice.)

Thanks Thomas, your explanation helps, let's see how I go.

> The https protocol would add quite some overhead to the download of the
iso-files

Well we could have it on just the checksums files, that would be a negligible 
overhead.

Checking a single checksum based on an https page seems far easier than 
verifying a file to verify a file to verify a file...


Regards
Matt

(Sorry about the lack of pleasantries in my previous email. I haven't used 
these sorts of mailing lists before, so I just assumed it was all about going 
straight to business like on Stack Exchange.)

Re: Mailing-list configuration

[Lisi Reisz]

On Thursday 16 June 2016 13:47:54 Dan Purgert wrote:
> In addition, I feel that both parties in the original problem
> (apparently Lisi and Nicolas -- please correct me if I'm wrong) each
> have some fault in the matter.  Mainly, this seems to stem from each of
> you assuming that the other's MUA behaves similarly to your own, and
> then perhaps having sent one (or several) mails that were viewed by the
> other as inflammatory; even if you didn't necessarily mean it that way.

You are right that I am probably "newer" than Nicolas in this field, though 
probably older in the world in general :-/.  You are wrong in saying that I 
assumed anything.  I requested him to cease sending me personal replies AS 
WELL AS list replies as getting the two causes me problems, and the CoC 
specifically forbids ccs..  He initially did so, and I thanked him for it.  
(The CoC also, of course, specifically forbids me to complain about ccs on 
list!)  After that, I did not really engage with him, apart from asking him 
what was wrong with my headers, and, then, how to put to put it right.  I 
have no idea how Mutt works, and would not presume to suggest that I did.

As for changing my own behaviour, I have done so.   I would be perfectly 
willing to set up every folder in my email client to use different headers, 
as advocated by Nicolas, but I have no idea how to do it.  I had enough 
trouble making the different folders use different SMTP servers!!

As a direct result of this thread, I have deleted the "reply" icon button from 
my email client.  This forces me to stop and think every time I want to reply 
to a mail, private or list, and prevents me from clicking on "reply" in cases 
where a correspondent on this list has put his or her name in a reply to 
header.  In these circumstances that header over-rides the setting in my 
email client to reply to list if the button is clicked.  I now can't click 
the button and accidentally reply to sender.  I apologise to those to whom I 
have done it in the past when I forgot - too frequently - *not* to click on 
the icon.

In the end, however, we are all at each others' mercy. :-/

This morning someone obeyed the CoCs and did not send me a cc - instead he 
added me to the recipient list.  It gives Jesuitical a new meaning.  I do not 
understand my fellow human beings.  How can anyone get pleasure from taking 
trouble to be a nuisance  

Lisi

Re: Missing signatures for installer checksums

[Brian]

On Thu 16 Jun 2016 at 08:18:18 -0400, Jude DaShiell wrote:

> maybe an easier way if Sarah has smtp working on her debian box. Install
> report-bug and run it.  If everything gets filled in correctly and
> report-bug can actually send an e-mail, the bug report will be filed
> correctly with everything debian expects.

No local MTA needed for reportbug. Use 'smtphost bugs.debian.org' in the
configuration file.

> >On 06/15/2016 10:58 PM, Sarah Newman wrote:
> >>
> >>Are the signatures somewhere else, and if not where should a bug be filed?

There does not appear to be a bug to report.

  http://ftp.debian.org/debian/dists/jessie/main/installer-i386/current/images/

Re: How to download over https

[Lisi Reisz]

On Thursday 16 June 2016 14:41:22 Matthew Davis wrote:
> (Sorry about the lack of pleasantries in my previous email. I haven't used
> these sorts of mailing lists before, so I just assumed it was all about
> going straight to business like on Stack Exchange.)

Both your emails seemed fine to me. :-)  Your lack of verbosity will greatly 
have pleased some people!

Lisi

Re: testing, rhythmbox err msg "Failed to open output device: Unable to prepare device"

[songbird]

Sven Arvidsson wrote:
...
> Most likely a problem with Gstreamer, is=C2=A0gstreamer1.0-alsa installed?

  pulseaudio was too noisy, took it out again, left
gstreamer alone.  things now work like before with
alsa.

  thanks again, :)


  songbird

Re: Mailing-list configuration

[Dan Purgert]

Lisi Reisz wrote:
> On Thursday 16 June 2016 13:47:54 Dan Purgert wrote:
>> In addition, I feel that both parties in the original problem
>> (apparently Lisi and Nicolas -- please correct me if I'm wrong) each
>> have some fault in the matter.  Mainly, this seems to stem from each of
>> you assuming that the other's MUA behaves similarly to your own, and
>> then perhaps having sent one (or several) mails that were viewed by the
>> other as inflammatory; even if you didn't necessarily mean it that way.
>
> You are right that I am probably "newer" than Nicolas in this field,
> though probably older in the world in general :-/.  You are wrong in
> saying that I assumed anything.  

Fair enough - as I said, I'm not privy to how the whole mess started,
just stating my observations (and assumptions) based on the back & forth
in the thread in general.


> As for changing my own behaviour, I have done so.   I would be perfectly 
> willing to set up every folder in my email client to use different
> headers, as advocated by Nicolas, but I have no idea how to do it.  I
> had enough trouble making the different folders use different SMTP
> servers!!

Can't particularly help there, as I don't know what client you're using.
Though some of the "newer" ones are horrific in the amount of
"customization" that you're not allowed to do (because the writer didn't
think anyone would need / want it ... yay!)

> [snip]
> In the end, however, we are all at each others' mercy. :-/
Indeed we are.  The people who send HTML messages often create "fun"
issues (as my client expects text alone).  But, "text only" is now
seemingly the "alternate" rather than the "default behavior" for sending
emails.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 

Re: Mailing-list configuration

[Lisi Reisz]

On Thursday 16 June 2016 16:31:21 Dan Purgert wrote:
> > In the end, however, we are all at each others' mercy. :-/
>
> Indeed we are.  The people who send HTML messages often create "fun"
> issues (as my client expects text alone).  But, "text only" is now
> seemingly the "alternate" rather than the "default behavior" for sending
> emails.

Some people seem to find text only impossible.  My grocery supplier (or one of 
them) refuses to send order acknowledgements in plain text or 
multi-part/alternative, so I have real difficulty reading them and have given 
up.  If the wrong thing arrives too bad.  And yes, I am taking as much of my 
business away from them as I can, without cutting off my nose to spite my 
face.

Lisi

Re: How to download over https

[Dan Purgert]

matthew wrote:
> [snip]
>
> There are MD5 and SHA sums in that same directory. However I can only
> access those checksums through unencrypted connections. Therefore they
> cannot be used to check against 3rd party tampering. (Since someone
> who has the ability to tamper with the .iso can also tamper with the
> .txt files.)

I don't think you quite get how "HTTPS" works, or rather what "HTTPS"
implies. All it means is that the transport channel itself (in this
case, HTTP) is secured from someone eavesdropping on the connection
(and, by extension, it's not being modified on the fly), and that the
server at the other end is what it says it is (i.e. a cert for
"https://www.example.com"; will cause your browser to error if you get
redirected to "https://honeypot.example.com";).

It DOES NOT protect you from a malicious party who has "tampered" with
the iso image itself, and is presenting that tampered file as the
original (the way to verify THAT information is with checksums and
digital signatures).

For example, let's say you ask for a link to "some_package.deb" (because
it's old / unmaintained -- like Adobe Reader -- and you need to use it
because some Windows fool sent you something that relies on that package
to work).  Without a checksum or signature on the file, even if I send
you a https link (e.g. "https://example.com/some_package.deb";), you
have no assurances that the package is ~really~ the one you're after (as
opposed to say, a rootkit).

So, the fact that HTTPS doesn't ~actually~ provide you with any security
when a "malicious party" has root accesss to the webserver, AND that it
adds overhead to the transmission (which, for an install ISO is pretty
big already), it's preferable to provide the files in the manner that
they have been (i.e. HTTP with detached signatures / checksums).  Note
too that the checksum information and digital signature source SHOULD be
provided in an out-of-band (and secure) manner so as to create a strong
web of trust.  

Given that "debian" is the "well-trusted" party in this instance, their
providing of both 

 - their public signing key, AND
 - the *.iso MD5 and/or SHA checksum(s) 

on a HTTPS-secured webpage will suffice the conditions of "creating
trust" for most people.

Further strengthening of this trust can be had by the public PGP key
being itself signed by well-known and well-trusted individuals in the
community (even if they're only 'marginally' trusted by you, GPG
defaults to '3 marginals = okay' for trust purposes -- although you can
still verify a signature even without "trusting" the key).

>
> Am I supposed to be able to use https? If not, how can I download
> debian iso files securely?

No. As explained, you don't need to "download" them securely, but rather
have a secure means to validate the data you get is the data you expect.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 

open - resource temporarily unavailable

[Andrew P. Cherepenko]

Hello list,
  'open()' for creating file sometimes returns an error:
couldn't open "myfile.txt": resource temporarily unavailable
either in background process or interactively (ex: in Emacs when 
trying to save a file).


system: Debian 8.5
with kernel: linux-image-3.16.0-4-amd64
and systemd 215-17+deb8u4

Is that concerned with some imposed limits on the kernel resources ?

Following comprehensible suggestions about checking/changing such limits 
from here:

http://unix.stackexchange.com/questions/253903/creating-threads-fails-with-resource-temporarily-\
unavailable-with-4-3-kernel

I checked my circumstances.

me:~$ cat /proc/sys/kernel/threads-max
96126

me:~$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 48063
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 65536
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 32768
cpu time   (seconds, -t) unlimited
max user processes  (-u) 48063
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

me:~$ ls -1d /proc/*/task/* | wc -l
618

I thought the most important - the limit on open files:
me:~$ ulimit -n
65536

But in use there are:
jeder@mhfpklytstime:~$ lsof | wc -l
26117

So those seemingly reasonable suggestions gave me nothing.
It is quite upsetting too that
  neither the journal nor /var/log/syslog even mentioned the errors.

Am I missing something basic ?


Thanks,
  Andrey

error trying to launch the first firefox window on Debian Jessie

[Dalios]

Hi list,

my system is Debian 8 Jessie (stable) with XFCE Desktop Environment and
just a few days back my Iceweasel browser transformed to Firefox. After
that my keyboard shortcut for launching Firefox isn't working if Firefox
isn't running! In other words: if a Firefox Window is open then I can
launch other (new) Firefox windows with my shortcut but if no Firefox
windows are open the none starts.

From: XFCE Menu >> Keyboard >> Application Shortcuts I found the exact
command which was "exo-open --launch WebBrowser" so I tried that on a
console and got this error:


--8><-

dalios@debian-8:~$ exo-open --launch WebBrowser
dalios@debian-8:~$ 1466093150530addons.xpi  WARNException 
running
bootstrap method startup on {fe272bd1-5f76-4ea4-8501-a05d35d823fc}:
ReferenceError: invalid assignment left-hand side
(resource://gre/modules/addons/XPIProvider.jsm ->
jar:file:///home/dalios/.mozilla/firefox/5k17vuc8.default/extensions/%7Bfe272bd1-5f76-4ea4-8501-a05d35d823fc%7D.xpi!/bootstrap.js
->
jar:file:///home/dalios/.mozilla/firefox/5k17vuc8.default/extensions/%7Bfe272bd1-5f76-4ea4-8501-a05d35d823fc%7D.xpi!/lib/ui.js:407:5)
JS Stack trace: requ...@bootstrap.js:141:4 < @main.js:19:1 <
requ...@bootstrap.js:141:4 < star...@bootstrap.js:28:2 <
this.xpiprovider.callbootstrapmet...@xpiprovider.jsm:4656:9 <
this.xpiprovider.star...@xpiprovider.jsm:2727:13 <
callprovi...@addonmanager.jsm:227:12 <
_startprovi...@addonmanager.jsm:833:5 <
addonmanagerinternal.star...@addonmanager.jsm:1016:9 <
this.addonmanagerprivate.star...@addonmanager.jsm:2782:5 <
ammanager.prototype.obse...@addonmanager.js:58:7

--><8paste-ends-here---><8-



If I try the command "firefox" (or "iceweasel") then a similar error is
produced but at least Firefox is launched.


--8><-

dalios@debian-8:~$ firefox
1466095187537   addons.xpi  WARNException running bootstrap method 
startup
on {fe272bd1-5f76-4ea4-8501-a05d35d823fc}: ReferenceError: invalid
assignment left-hand side (resource://gre/modules/addons/XPIProvider.jsm
->
jar:file:///home/dalios/.mozilla/firefox/5k17vuc8.default/extensions/%7Bfe272bd1-5f76-4ea4-8501-a05d35d823fc%7D.xpi!/bootstrap.js
->
jar:file:///home/dalios/.mozilla/firefox/5k17vuc8.default/extensions/%7Bfe272bd1-5f76-4ea4-8501-a05d35d823fc%7D.xpi!/lib/ui.js:407:5)
JS Stack trace: requ...@bootstrap.js:141:4 < @main.js:19:1 <
requ...@bootstrap.js:141:4 < star...@bootstrap.js:28:2 <
this.xpiprovider.callbootstrapmet...@xpiprovider.jsm:4656:9 <
this.xpiprovider.star...@xpiprovider.jsm:2727:13 <
callprovi...@addonmanager.jsm:227:12 <
_startprovi...@addonmanager.jsm:833:5 <
addonmanagerinternal.star...@addonmanager.jsm:1016:9 <
this.addonmanagerprivate.star...@addonmanager.jsm:2782:5 <
ammanager.prototype.obse...@addonmanager.js:58:7


--><8paste-ends-here---><8-


A similar problem is that when I click on a link on a document or an
application (for example Icedove, yes that is still Icedove and not
Thunderbird) then nothing happens unless firefox is already running.

I searched the web with the above errors (and parts of them) but didn't
come up with anything useful.

Any ideas?


Thanks in advance,
Dalios

Re: Missing signatures for installer checksums

[Sarah Newman]

On 06/16/2016 07:44 AM, Brian wrote:
> On Thu 16 Jun 2016 at 08:18:18 -0400, Jude DaShiell wrote:
> 
>> maybe an easier way if Sarah has smtp working on her debian box. Install
>> report-bug and run it.  If everything gets filled in correctly and
>> report-bug can actually send an e-mail, the bug report will be filed
>> correctly with everything debian expects.
> 
> No local MTA needed for reportbug. Use 'smtphost bugs.debian.org' in the
> configuration file.

Figuring out how to file the bug report isn't a problem. The problem is I don't 
know what component is responsible for generating either the existing
checksum files or the .sign files for the ISOs. I guess it could be filed as a 
"general" bug https://bugs.debian.org/general if nobody knows where it
should really be filed.

>>> On 06/15/2016 10:58 PM, Sarah Newman wrote:

 Are the signatures somewhere else, and if not where should a bug be filed?
> 
> There does not appear to be a bug to report.
> 
>   
> http://ftp.debian.org/debian/dists/jessie/main/installer-i386/current/images/
> 

Are there signatures for the checksum files somewhere in there?

Thanks, Sarah

Re: How to download over https

[Pascal Hambourg]

Le 16/06/2016 18:18, Dan Purgert a écrit :
1)

So, the fact that HTTPS doesn't ~actually~ provide you with any security
when a "malicious party" has root accesss to the webserver,




AND that it
adds overhead to the transmission


Does it really add network overhead of just CPU overhead on the server ?

2)

Given that "debian" is the "well-trusted" party in this instance, their
providing of both

  - their public signing key, AND
  - the *.iso MD5 and/or SHA checksum(s)

on a HTTPS-secured webpage will suffice the conditions of "creating
trust" for most people.


1) and 2) sound contradictory to me.

Re: error trying to launch the first firefox window on Debian Jessie

[Gene Heskett]

On Thursday 16 June 2016 12:48:42 Dalios wrote:

> Hi list,
>
> my system is Debian 8 Jessie (stable) with XFCE Desktop Environment
> and just a few days back my Iceweasel browser transformed to Firefox.
> After that my keyboard shortcut for launching Firefox isn't working if
> Firefox isn't running! In other words: if a Firefox Window is open
> then I can launch other (new) Firefox windows with my shortcut but if
> no Firefox windows are open the none starts.
>
> From: XFCE Menu >> Keyboard >> Application Shortcuts I found the exact
> command which was "exo-open --launch WebBrowser" so I tried that on a
> console and got this error:
>
>
> --8><-
>
> dalios@debian-8:~$ exo-open --launch WebBrowser
> dalios@debian-8:~$ 1466093150530  addons.xpi  WARNException 
> running
> bootstrap method startup on {fe272bd1-5f76-4ea4-8501-a05d35d823fc}:
> ReferenceError: invalid assignment left-hand side
> (resource://gre/modules/addons/XPIProvider.jsm ->
> jar:file:///home/dalios/.mozilla/firefox/5k17vuc8.default/extensions/%
>7Bfe272bd1-5f76-4ea4-8501-a05d35d823fc%7D.xpi!/bootstrap.js ->
> jar:file:///home/dalios/.mozilla/firefox/5k17vuc8.default/extensions/%
>7Bfe272bd1-5f76-4ea4-8501-a05d35d823fc%7D.xpi!/lib/ui.js:407:5) JS
> Stack trace: requ...@bootstrap.js:141:4 < @main.js:19:1 <
> requ...@bootstrap.js:141:4 < star...@bootstrap.js:28:2 <
> this.xpiprovider.callbootstrapmet...@xpiprovider.jsm:4656:9 <
> this.xpiprovider.star...@xpiprovider.jsm:2727:13 <
> callprovi...@addonmanager.jsm:227:12 <
> _startprovi...@addonmanager.jsm:833:5 <
> addonmanagerinternal.star...@addonmanager.jsm:1016:9 <
> this.addonmanagerprivate.star...@addonmanager.jsm:2782:5 <
> ammanager.prototype.obse...@addonmanager.js:58:7
>
> --><8paste-ends-here---><8-
>
>
>
> If I try the command "firefox" (or "iceweasel") then a similar error
> is produced but at least Firefox is launched.
>
>
There seems to be sort of a "quantum dis-entanglement" in this browser 
transition (and I am reading between the lines, thinking your problem is 
related to this) because in one swell foop they've disabled the help 
menu's of quite a few programs that used iceweasel as their reader for 
html docs, whether it was a file on your own machine, or a link to a 
site on the web serving up the latest docs, which of course do NOT apply 
to the 3 year old stable versions of the programs served up by the 
repo's

I solved it here the hard, no doubt totally unapproved way, I 
copied /usr/lib/firefox to /usr/lib/iceweasel and then made softlinks in 
the copied directory from iceweasel to firefox.  And those programs that 
serve up their help menu's with iceweasel are once again "fat, dumb, and 
happy".

Tain't right, it will not be updated, but in that event I'll just edit 
the softlinks to actually reference the real thing & nuke the rest of 
that directory as wasted  disk space.

I have no clue what they were thinking when they yanked iceweasel out by 
the roots. I doubt they even considered that something else might be 
dependent on iceweasel/iceweasel as a name.

What should have happened was that iceweasel was updated to be an empty 
package except for that /usr/lib/iceweasel directory and the softlinks 
to firefox.

Grof in the general direction of TPTB.

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 

Apt periodic doesn't work

[Jayson Willson]

Hello! I use Debian Stable. Recently I have installed 
unattended-upgrades package, so as to have apt lists updated and 
possible upgrades downloaded automatically (while I do not want them to 
be installed automatically). However, though I think I have configured 
everything correctly, apt doesn't update package lists automatically (I 
have been using my computer for three days since then and update did not 
take place).


Here is my /etc/apt/apt.conf.d/20auto-upgrades:
http://ix.io/TvB
Here is my /etc/apt/apt.conf.d/50unattended-upgrades:
http://ix.io/TvC
Here is my apt-config dump output:
http://ix.io/TvD
Here is my /etc/cron.daily/apt:
http://ix.io/TvE
According to systemctl status cron, cron is running.
Could you please help me with this problem? Thanks in advance.

--
Yours sincerely, Jayson Willson

Re: Missing signatures for installer checksums

[John Hasler]

Sarah writes:
> Figuring out how to file the bug report isn't a problem. The problem
> is I don't know what component is responsible for generating either
> the existing checksum files or the .sign files for the ISOs.

Then file the bug against your best guess as to the culprit.  The
maintainer will reassign the bug as necessary.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: boot times out after dist-upgrade on Stretch

[Borden Rhodes]

Thank you for getting back to me, Sven,

I normally run apt-get update; apt-get dist-upgrade immediately after
my computer boots. According to the messages log, I turned the
computer on about 5 minutes before running that command and the last
log entry was about 3.5 hours later at 22:59. I hadn't fiddled with
any other settings during that boot. Unfortunately, without /var
loading on the dead boots, I can't get any log information except when
I successfully boot into the recovery console.

I should have mentioned that I also tried booting from the 4.5 kernel
and got the exact same symptoms. I also tried running update-grub in
case it had made a mistake whilst installing the 4.6 kernel.

Notwithstanding better ideas, I'm thinking of doing the Windows Safe
Mode troubleshooting method where I work out the systemd differences
between the default and recovery targets and gradually add services
until I find the one that breaks the system. I'm inferring that, since
recovery mode works but normal mode doesn't, then one of the
targets/services in normal mode is to blame for the lock up. I don't
suppose I could trouble the list for a resource on how to do that?

> Date: Wed, 15 Jun 2016 19:35:34 +0200
> From: Sven Joachim 
> To: debian-user@lists.debian.org
> Subject: Re: boot times out after dist-upgrade on Stretch
> Message-ID: <8760tapd7d@turtle.gmx.de>
> Content-Type: text/plain
>
> On 2016-06-15 07:58 +, Borden Rhodes wrote:
>
>> I ran apt dist-upgrade on Stretch (with a few Sid packages) which made
>> the following changes:
>>
>> Start-Date: 2016-06-14  19:42:39
>> Commandline: apt-get dist-upgrade
>> Requested-By: me (1000)
>> Install: libdw1:amd64 (0.163-5.1, automatic),
>> linux-image-4.6.0-1-amd64:amd64 (4.6.1-1, automatic)
>> Upgrade: wwwconfig-common:amd64 (0.2.2, 0.3.0), libcomerr2:amd64
>> (1.43-3, 1.43.1-1), libcomerr2:i386 (1.43-3, 1.43.1-1), libcups2:amd64
>> (2.1.3-5, 2.1.3-6), fuse2fs:amd64 (1.43-3, 1.43.1-1), e2fsprogs:amd64
>> (1.43-3, 1.43.1-1), boinc-client:amd64 (7.6.32+dfsg-2, 7.6.33+dfsg-1),
>> libbabeltrace1:amd64 (1.3.2-1, 1.4.0-1), cups-server-common:amd64
>> (2.1.3-5, 2.1.3-6), e2fslibs:amd64 (1.43-3, 1.43.1-1),
>> cups-common:amd64 (2.1.3-5, 2.1.3-6), libspice-server1:amd64
>> (0.12.6-4, 0.12.6-4.1), boinc-manager:amd64 (7.6.32+dfsg-2,
>> 7.6.33+dfsg-1), libss2:amd64 (1.43-3, 1.43.1-1), live-config-doc:amd64
>> (5.20151121, 5.20160608), libdatetime-timezone-perl:amd64
>> (1:1.98-1+2016d, 1:2.00-1+2016d), cups-ppdc:amd64 (2.1.3-5, 2.1.3-6),
>> libcupsmime1:amd64 (2.1.3-5, 2.1.3-6), python-paramiko:amd64
>> (1.16.0-1, 2.0.0-1), linux-image-amd64:amd64 (4.5+73, 4.6+74),
>> libboinc7:amd64 (7.6.32+dfsg-2, 7.6.33+dfsg-1), libcupsppdc1:amd64
>> (2.1.3-5, 2.1.3-6), libbabeltrace-ctf1:amd64 (1.3.2-1, 1.4.0-1),
>> live-config:amd64 (5.20151121, 5.20160608), cups-bsd:amd64 (2.1.3-5,
>> 2.1.3-6), cups-core-drivers:amd64 (2.1.3-5, 2.1.3-6),
>> cups-daemon:amd64 (2.1.3-5, 2.1.3-6), libcupsimage2:amd64 (2.1.3-5,
>> 2.1.3-6), cups:amd64 (2.1.3-5, 2.1.3-6), boinc:amd64 (7.6.32+dfsg-2,
>> 7.6.33+dfsg-1), libcupscgi1:amd64 (2.1.3-5, 2.1.3-6),
>> cups-client:amd64 (2.1.3-5, 2.1.3-6), live-config-systemd:amd64
>> (5.20151121, 5.20160608), libjpeg62-turbo:amd64 (1:1.4.2-2,
>> 1:1.5.0-1), libjpeg62-turbo:i386 (1:1.4.2-2, 1:1.5.0-1), xterm:amd64
>> (324-2, 325-1)
>> End-Date: 2016-06-14  19:46:44
>
> The only package related to the boot process seems to be
> linux-image-4.6.0-1-amd64.  However, there could be others which were
> upgraded earlier.  When did you last boot before this upgrade?
>
>> The system worked normally until I rebooted a few hours later. After
>> entering my encryption password (more on that later), boot up stalls
>> with a message saying that "A start job is running for" and then
>> switches between sda5_crypt.device, x2dhome.device, x2dvar.device,
>> x2dtmp.device, .device and
>> .device.
>>
>> After 90 seconds, the start up jobs timeout and the boot tries to
>> start an emergency shell. However, the prompt never appears, responds
>> to ^C or ^D as some suggest it might. However, CTRL+ALT+DEL works, so
>> I know the system isn't completely locked up.
>>
>> The only error messages I can read after that, as earlier ones would
>> get truncated, are that systemd-tmpfiles.setup.service,
>> binfmt-support.service and networking.service all failed to start.
>
> Those probably fail because /tmp and /var could not be mounted.
>
>> I can, however, boot into single user recovery without the stall,
>> timetout or any error messages.
>>
>> I think it's relevant to note that my hard drive has a msdos partition
>> table (and a legacy BIOS), a LVM partition containing dm-crypt'd
>> partitions, each of which is formatted with a btrfs file system. Put
>> another way, here's my fstab:
>> #
>> /dev/mapper/LVG-root /   btrfs   defaults0   1
>> # /boot was on /dev/sda1 during installation
>> UUID= /boot   btrfs   defaults0   2
>> /dev/mapper

Re: Missing signatures for installer checksums

[Brian]

On Thu 16 Jun 2016 at 13:04:35 -0500, John Hasler wrote:

> Sarah writes:
> > Figuring out how to file the bug report isn't a problem. The problem
> > is I don't know what component is responsible for generating either
> > the existing checksum files or the .sign files for the ISOs.
> 
> Then file the bug against your best guess as to the culprit.  The
> maintainer will reassign the bug as necessary.

Filing a bug against the pseudopackage debian-cd gets ypu pretty close
to those responsible.

Functional Difference of dpkg --get-selections vs --get-selections "*"

[Bruce Gates]

Hello,


Noob question for y'all...


What is the functional difference between dpkg --get-selections and dpkg 
--get-selections "*"?


It seems to me that the first command would find all packages anyway, making 
the wildcard erroneous...perhaps I'm mistaken?


Thanks guys and gals!


Bruce

Re: open - resource temporarily unavailable

[Sven Joachim]

On 2016-06-16 21:46 +0600, Andrew P. Cherepenko wrote:

> Hello list,
>   'open()' for creating file sometimes returns an error:
> couldn't open "myfile.txt": resource temporarily unavailable
> either in background process or interactively (ex: in Emacs when
> trying to save a file).

Are you sure that it's opening the file which fails in that way, and not
writing to it?  Because, according to the manpages, EAGAIN is a possible
error in write(2), but not in open(2).  Quoting the write() manpage:

,
| EAGAIN The file descriptor fd refers to a file other than a socket
|and has been marked nonblocking (O_NONBLOCK), and the write
|would block.  See open(2) for further details on the O_NON‐
|BLOCK flag.
`

> system: Debian 8.5
> with kernel: linux-image-3.16.0-4-amd64
> and systemd 215-17+deb8u4
>
> Is that concerned with some imposed limits on the kernel resources ?

Probably not.  The only limit that should play a role here is the number
of file descriptors, and the error would be EMFILE ("Too many open
files") rather than EAGAIN.

Cheers,
   Sven

Re: Apt periodic doesn't work

[Teemu Likonen]

Jayson Willson [2016-06-16 20:54:12+03] wrote:

> Hello! I use Debian Stable. Recently I have installed
> unattended-upgrades package, so as to have apt lists updated and
> possible upgrades downloaded automatically (while I do not want them
> to be installed automatically). However, though I think I have
> configured everything correctly, apt doesn't update package lists
> automatically (I have been using my computer for three days since then
> and update did not take place).

I'd check logs at /var/log/unattended-upgrades directory and manually
run command "unattended-upgrades -v" (as root). Also, the apt-daily
script has a laptop check which makes it skip if on_ac_power command
returns 1 (not on AC power).

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: Apt periodic doesn't work

[Jayson Willson]

There is only one empty file named unattended-upgrades-shutdown.log in 
this directory.

unattended-upgrades:
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,codename=jessie,label=Debian-Security']
No packages found that can be upgraded unattended

There are really no packages to upgrade, because in the morning I ran 
apt update and apt upgrade manually. Actually, I do not want packages to 
upgrade automatically, I only need checking for upgrades and downloading 
them.


My computer is not a laptop

Yours sincerely, Jayson Willson

16.06.2016 21:55, Teemu Likonen пишет:

Jayson Willson [2016-06-16 20:54:12+03] wrote:


Hello! I use Debian Stable. Recently I have installed
unattended-upgrades package, so as to have apt lists updated and
possible upgrades downloaded automatically (while I do not want them
to be installed automatically). However, though I think I have
configured everything correctly, apt doesn't update package lists
automatically (I have been using my computer for three days since then
and update did not take place).


I'd check logs at /var/log/unattended-upgrades directory and manually
run command "unattended-upgrades -v" (as root). Also, the apt-daily
script has a laptop check which makes it skip if on_ac_power command
returns 1 (not on AC power).

Re: Functional Difference of dpkg --get-selections vs --get-selections "*"

[Sven Joachim]

On 2016-06-16 18:36 +, Bruce Gates wrote:

> What is the functional difference between dpkg --get-selections and dpkg 
> --get-selections "*"?

>From the manpage:

,
|  --get-selections [package-name-pattern...]
| Get list of package selections, and  write  it  to  stdout.
| Without a pattern, non-installed packages (i.e. those which
| have been previously purged) will not be shown.
`

In most cases the output will be the same, though.

> It seems to me that the first command would find all packages anyway,
> making the wildcard erroneous...perhaps I'm mistaken?

There is a difference if you have selected currently purged packages for
installation, e.g. with "dpkg --set-selections":

,
| # apt-get install dselect && dselect update && echo "ed install" | dpkg 
--set-selections
| [...]
| # diff -u <(dpkg --get-selections) <(dpkg --get-selections "*")
| --- /dev/fd/63  2016-06-16 19:36:02.856792917 +
| +++ /dev/fd/62  2016-06-16 19:36:02.856792917 +
| @@ -31,6 +31,7 @@
|  dselectinstall
|  e2fslibs:i386  install
|  e2fsprogs  install
| +ed install
|  fakeroot   install
|  file   install
|  findutils  install
`

Old versions of dpkg also used to keep information about packages in the
status file after purging them, but this was changed in dpkg 1.15.4¹.

Cheers,
   Sven


¹. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472208

Re: How to download over https

[Dan Purgert]

Pascal Hambourg wrote:
> Le 16/06/2016 18:18, Dan Purgert a écrit :
> 1)
>> So, the fact that HTTPS doesn't ~actually~ provide you with any security
>> when a "malicious party" has root accesss to the webserver,
>
>
>> AND that it
>> adds overhead to the transmission
>
> Does it really add network overhead of just CPU overhead on the server ?

CPU on both ends, as well as making the overall amount of data
transmitted somewhat larger.  This is because encrypted blocks have
specific size requirements (if you're familiar with base-64 encoding,
that's why the data usually ends with '==' -- it's an indicator that the
encoding process ran out of data before the block was full, and is
padding it out).

Remeber that a single packet can only carry 1460 bytes, before
accounting for services that specify MTUs <1500 .  If you're using
something like 64-byte blocks for the encryption scheme (which is fairly
common, so I'm going with that from here on out), you're limited to only
sending 1408 bytes / packet of actual data, assuming zero overhead.  For
the 660 602 880 bytes of "cd1" from the debian installer suite, this
means you're transmitting 469,178 fully loaded packets, plus 1 partial
(approx 315 bytes) ... or a total transmission of 689 691 975 bytes.

For plain HTTP with 1460-byte payloads, it's only 452,467 full packets,
plus 1 partial (approx 1100 bytes) ... or a total transmission of 678
701 600 bytes.

Sure, a savings 10 MB is only 1.6% of the original image size - but then
you need to look at how many copies of the CD are downloaded (I don't
know that). Works out to every 63rd download creates enough overhead
that you've effectively transmitted another full image in overhead alone.

>
> 2)
>> Given that "debian" is the "well-trusted" party in this instance, their
>> providing of both
>>
>>   - their public signing key, AND
>>   - the *.iso MD5 and/or SHA checksum(s)
>>
>> on a HTTPS-secured webpage will suffice the conditions of "creating
>> trust" for most people.
>
> 1) and 2) sound contradictory to me.

I apologize, as a phone call distracted me, and I inadvertantly missed
this during editing.  It should read as follows:

=
Given that "Debian" is a well-trusted party (insofar as distributing
'debian installation cds'), the fact that they provide both:

 - their public signing key (signed by 33 other individuals), AND
 - various signed checksum lists (MD5 / SHA1 / SHA2 / etc.)

out-of-band to the CD images themselves (i.e. it's not a tarball
containing all three pieces of information) creates conditions that
suffice as "trustworthy" for the case of ensuring the CD image you get
isn the one you were intended to get by the Debian team.
=

Remember too, that the TLS certificate is ONLY providing verification
the server is who it says it is (e.g. "www.example.com"), and encrypting
the session.  It does nothing to prove that the data contained on a
mirror is the data that the upstream party intended you to get.

So if a mirror was providing a broken CD image (either due to a
technical error, or operator malice), even having it provide that image
over HTTPS would not 'protect' you from burning that invalid image to a
CD, and then having a bad night when it fails install 98% of the way
through.  And that's not even considering an error at your end.

So, that's where the checksums come in.  You WILL NOT get the same
checksum if your newly downloaded image was corrupted in transit (or was
no good at the remote end in the first place).  

Now, since people have expressed concerns over ensuring the validity of
the checksums themselves, they get signed with the Debian CD signing key
(Debian CD signing key ), of which the
public key is signed by no fewer than 30 people. And, because the only
way to get a valid signature from that private key is to have access to
that private key (and its passphrase), someone downloading the files can
then verify the checksum file is signed by the right party (i.e.
"Debian"), and then they can compare the checksum of the downloaded CD
image against the now known-good checksums.  If the iso checksum matches
the checksum in the list, the iso image is now known-good (and one can
proceed to using it for installation).

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 

Re: boot times out after dist-upgrade on Stretch

[Mark Fletcher]

On Fri, 17 Jun 2016 at 03:12, Borden Rhodes  wrote:

> Thank you for getting back to me, Sven,
>
> I normally run apt-get update; apt-get dist-upgrade immediately after
> my computer boots. According to the messages log, I turned the
> computer on about 5 minutes before running that command and the last
> log entry was about 3.5 hours later at 22:59. I hadn't fiddled with
> any other settings during that boot. Unfortunately, without /var
> loading on the dead boots, I can't get any log information except when
> I successfully boot into the recovery console.
>
> I should have mentioned that I also tried booting from the 4.5 kernel
> and got the exact same symptoms. I also tried running update-grub in
> case it had made a mistake whilst installing the 4.6 kernel.
>
> Notwithstanding better ideas, I'm thinking of doing the Windows Safe
> Mode troubleshooting method where I work out the systemd differences
> between the default and recovery targets and gradually add services
> until I find the one that breaks the system. I'm inferring that, since
> recovery mode works but normal mode doesn't, then one of the
> targets/services in normal mode is to blame for the lock up. I don't
> suppose I could trouble the list for a resource on how to do that?
>
> > Date: Wed, 15 Jun 2016 19:35:34 +0200
> > From: Sven Joachim 
> > To: debian-user@lists.debian.org
> > Subject: Re: boot times out after dist-upgrade on Stretch
> > Message-ID: <8760tapd7d@turtle.gmx.de>
> > Content-Type: text/plain
> >
> > On 2016-06-15 07:58 +, Borden Rhodes wrote:
> >
> >> I ran apt dist-upgrade on Stretch (with a few Sid packages) which made
> >> the following changes:
> >>
> >> Start-Date: 2016-06-14  19:42:39
> >> Commandline: apt-get dist-upgrade
> >> Requested-By: me (1000)
> >> Install: libdw1:amd64 (0.163-5.1, automatic),
> >> linux-image-4.6.0-1-amd64:amd64 (4.6.1-1, automatic)
> >> Upgrade: wwwconfig-common:amd64 (0.2.2, 0.3.0), libcomerr2:amd64
> >> (1.43-3, 1.43.1-1), libcomerr2:i386 (1.43-3, 1.43.1-1), libcups2:amd64
> >> (2.1.3-5, 2.1.3-6), fuse2fs:amd64 (1.43-3, 1.43.1-1), e2fsprogs:amd64
> >> (1.43-3, 1.43.1-1), boinc-client:amd64 (7.6.32+dfsg-2, 7.6.33+dfsg-1),
> >> libbabeltrace1:amd64 (1.3.2-1, 1.4.0-1), cups-server-common:amd64
> >> (2.1.3-5, 2.1.3-6), e2fslibs:amd64 (1.43-3, 1.43.1-1),
> >> cups-common:amd64 (2.1.3-5, 2.1.3-6), libspice-server1:amd64
> >> (0.12.6-4, 0.12.6-4.1), boinc-manager:amd64 (7.6.32+dfsg-2,
> >> 7.6.33+dfsg-1), libss2:amd64 (1.43-3, 1.43.1-1), live-config-doc:amd64
> >> (5.20151121, 5.20160608), libdatetime-timezone-perl:amd64
> >> (1:1.98-1+2016d, 1:2.00-1+2016d), cups-ppdc:amd64 (2.1.3-5, 2.1.3-6),
> >> libcupsmime1:amd64 (2.1.3-5, 2.1.3-6), python-paramiko:amd64
> >> (1.16.0-1, 2.0.0-1), linux-image-amd64:amd64 (4.5+73, 4.6+74),
> >> libboinc7:amd64 (7.6.32+dfsg-2, 7.6.33+dfsg-1), libcupsppdc1:amd64
> >> (2.1.3-5, 2.1.3-6), libbabeltrace-ctf1:amd64 (1.3.2-1, 1.4.0-1),
> >> live-config:amd64 (5.20151121, 5.20160608), cups-bsd:amd64 (2.1.3-5,
> >> 2.1.3-6), cups-core-drivers:amd64 (2.1.3-5, 2.1.3-6),
> >> cups-daemon:amd64 (2.1.3-5, 2.1.3-6), libcupsimage2:amd64 (2.1.3-5,
> >> 2.1.3-6), cups:amd64 (2.1.3-5, 2.1.3-6), boinc:amd64 (7.6.32+dfsg-2,
> >> 7.6.33+dfsg-1), libcupscgi1:amd64 (2.1.3-5, 2.1.3-6),
> >> cups-client:amd64 (2.1.3-5, 2.1.3-6), live-config-systemd:amd64
> >> (5.20151121, 5.20160608), libjpeg62-turbo:amd64 (1:1.4.2-2,
> >> 1:1.5.0-1), libjpeg62-turbo:i386 (1:1.4.2-2, 1:1.5.0-1), xterm:amd64
> >> (324-2, 325-1)
> >> End-Date: 2016-06-14  19:46:44
> >
> > The only package related to the boot process seems to be
> > linux-image-4.6.0-1-amd64.  However, there could be others which were
> > upgraded earlier.  When did you last boot before this upgrade?
> >
> >> The system worked normally until I rebooted a few hours later. After
> >> entering my encryption password (more on that later), boot up stalls
> >> with a message saying that "A start job is running for" and then
> >> switches between sda5_crypt.device, x2dhome.device, x2dvar.device,
> >> x2dtmp.device, .device and
> >> .device.
> >>
> >> After 90 seconds, the start up jobs timeout and the boot tries to
> >> start an emergency shell. However, the prompt never appears, responds
> >> to ^C or ^D as some suggest it might. However, CTRL+ALT+DEL works, so
> >> I know the system isn't completely locked up.
> >>
> >> The only error messages I can read after that, as earlier ones would
> >> get truncated, are that systemd-tmpfiles.setup.service,
> >> binfmt-support.service and networking.service all failed to start.
> >
> > Those probably fail because /tmp and /var could not be mounted.
> >
> >> I can, however, boot into single user recovery without the stall,
> >> timetout or any error messages.
> >>
> >> I think it's relevant to note that my hard drive has a msdos partition
> >> table (and a legacy BIOS), a LVM partition containing dm-crypt'd
> >> partitions, each of which is formatted with a btrfs file system. Put
> >> another w

Re: boot times out after dist-upgrade on Stretch

[Borden Rhodes]

First, a huge shout out to /usr/share/doc/systemd/README.Debian.gz for
telling me that appending systemd.debug-shell to the linux line in
grub would let me run a shell even whilst the main boot couldn't drop
into an emergency shell. I think this should be writ in large friendly
letters at the start of any boot-related troubleshooting guide from
now on.

With that, I could dump journalctl and systemctl list-jobs to files.
In perusing these files, it confirms that boot chokes at 4
dev-disk-by\x2duuid-<...>.device, dev-mapper-sda5_crypt.device &
dev-mapper-LVG\x2d.device, but curiously not
dev-mapper-LVG\x2droot. root, of course, has a fstab pass value of 1
whereas the others have a pass value of 2. Is this a clue? The
list-jobs dumps also show some 94 other units waiting in line to run.

A little search-fu later, it seems I may have caught this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758808. However,
other searches on other distros suggest everything from hdparm needing
to be removed (didn't work), to incorrect fstab entries (did you guys
see any error in them?), to lunar cycles, to a butterfly flapping its
wings etc.

Anyhow, notwithstanding any better ideas, I think I'm going to
redirect this conversation to bug 758808.

> Date: Thu, 16 Jun 2016 13:56:48 -0400
> From: Borden Rhodes 
> To: debian-user@lists.debian.org
> Subject: Re: boot times out after dist-upgrade on Stretch
> Message-ID: 
> 
> Content-Type: text/plain; charset=UTF-8
>
> Thank you for getting back to me, Sven,
>
> I normally run apt-get update; apt-get dist-upgrade immediately after
> my computer boots. According to the messages log, I turned the
> computer on about 5 minutes before running that command and the last
> log entry was about 3.5 hours later at 22:59. I hadn't fiddled with
> any other settings during that boot. Unfortunately, without /var
> loading on the dead boots, I can't get any log information except when
> I successfully boot into the recovery console.
>
> I should have mentioned that I also tried booting from the 4.5 kernel
> and got the exact same symptoms. I also tried running update-grub in
> case it had made a mistake whilst installing the 4.6 kernel.
>
> Notwithstanding better ideas, I'm thinking of doing the Windows Safe
> Mode troubleshooting method where I work out the systemd differences
> between the default and recovery targets and gradually add services
> until I find the one that breaks the system. I'm inferring that, since
> recovery mode works but normal mode doesn't, then one of the
> targets/services in normal mode is to blame for the lock up. I don't
> suppose I could trouble the list for a resource on how to do that?