Re: /etc/apt/sources.list example [WAS Re: medically smart watches]

[gene heskett]

On 2/25/24 07:14, Andrew M.A. Cater wrote:


I have to agree, and pursuing that seems to disclose I do not have the
non-frre in my configs. So I'm now asking for help to add it to my
/etc/apt/sources *.list stuff.




For apt sources.list - have a look at:

https://wiki.debian.org/SourcesList


Thanks Andy.




Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

/etc/apt/sources.list example [WAS Re: medically smart watches]

[Andrew M.A. Cater]

On Sun, Feb 25, 2024 at 05:16:21AM -0500, gene heskett wrote:
> On 2/25/24 03:36, Geert Stappers wrote:
> > On Sat, Feb 24, 2024 at 02:05:50PM -0500, Lee wrote:
> > > On Sat, Feb 24, 2024 at 12:06 PM gene heskett wrote:
> > > > On 2/24/24 11:03, Loïc Grenié wrote:
> > > > > On Sat Feb 24th, 2024, at 16:03, Gene Heskett wrote:
> > > > > 
> > > > >  Greetings all;

> > > 
> > > What I'd like to find is software that lets me get the data off the
> > > reader into my PC.
> > 
> > As I see it, is https://wiki.debian.org/BluetoothUser now the best place
> > to go.
> > 
> I have to agree, and pursuing that seems to disclose I do not have the
> non-frre in my configs. So I'm now asking for help to add it to my
> /etc/apt/sources *.list stuff.
> > 

For apt sources.list - have a look at:

https://wiki.debian.org/SourcesList

> 

> > 
> > > Regards
> > > Lee
> > 
> > Groeten
> > Geert Stappers
> > 
> > About Original Poster:
> > I have never met Gene Heskett. When we will, I guess he will do 80%,
> > may be 90% of the talking, unlikely fifty-fifty. I think I will OK
> > with the non-balanced dialog, because I knew it from the begining.
> > Beside the difference in verboseness between Gene and me, there are lots
> > of common goals. For starters "Debian". Gene wrote in mailinglists posts
> > about his work as engineer, where he did serious trouble shooting.
> And yet. the one time the NAB had their annual broadcasters bash in D/FW I
> discovered I could be arrested in Texas for impersonating an Engineer
> because my business card said I was the CE at WDTV. but I was not a degree'd
> EE. That I'm not, I am a CET, a much more comprehensive final exam, we can
> teach the EE's things their prof's never touched, if the EE is willing to
> learn. Sadly, too many get the sheepskin and then turn off the learning
> because they already know it all. I don't generally waste a lot of time with
> them.
> 
> I've had EE's spend the night telling I'm wasting my time, it won't work.
> And are blown away, when I push the final button and it just works. I have
> no idea how many EE's there are here in the states, 10,000+ probably. There
> are only around 130 CET's.  Yet I have only an 8th grade diploma and a GED.
> Yet I know how simple things work, up to and including Einsteins theory's.
> as demonstrated by the time distortion a klystron amplifier does to a tv
> signal. I had to teach the FCC about that back in the '70's.
> 
> Computers are 1000 times more complex.
> 
> Cheers, Gene Heskett, CET.
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> 

Re: Apt sources.list

[Greg Wooledge]

On Thu, Apr 20, 2023 at 12:18:35PM +0200, Vincent Lefevre wrote:
> Anyway, in the time of freeze like now (probably with more
> users trying testing), isn't it important that testing gets
> security updates?

It's not really about what's "important", but what's feasible given the
available resources (time spent by the security team).

If the security team has the time to offer a handful of testing
updates -- which, apparently, they did at least once in the last few
months -- then that's great.  Everyone loves security updates.

However, their primary goal must, and will, remain supporting the stable
release(s).  Sometimes they struggle even doing that.

Re: Apt sources.list

[Vincent Lefevre]

On 2023-04-18 13:52:13 -0400, Jeffrey Walton wrote:
> On Tue, Apr 18, 2023 at 1:46 PM Frank  wrote:
> > Interesting. Like Tixy, I was under the impression testing didn't
> > receive security support. I remember checking that several times over
> > the years. Curious.

Anyway, in the time of freeze like now (probably with more
users trying testing), isn't it important that testing gets
security updates?

> I did not think so, either. But have a look at
> https://www.debian.org/security/faq#testing and

This one does not concern testing-security, but security updates
that "migrate" from unstable to testing, like any other update for
unstable (so this is just "testing", not "testing-security"):

  Security for testing benefits from the security efforts of the
  entire project for unstable. However, there is a minimum two-day
  migration delay, and sometimes security fixes can be held up by
  ^
  transitions. The Security Team helps to move along those transitions
  holding back important security uploads, but this is not always
  possible and delays may occur. Especially in the months after a new
  stable release, when many new versions are uploaded to unstable,
  security fixes for testing may lag behind. If you want to have a
  secure (and stable) server you are strongly encouraged to stay with
  stable.

There is a better solution concerning the "in the months after
a new stable release" case, even for users using unstable: have
"stable-security" in apt sources (e.g. /etc/apt/sources.list).
Since stable is new, most packages are based on the same version
as stable. That way, users can benefit from security updates for
stable.

> https://wiki.debian.org/DebianTesting .

This is strange that

  If you are tracking testing or the next-stable code name, you
  should always have a corresponding deb http://security.debian.org
  <"testing" or codename>-security main entry in your apt sources.
  See this FAQ-Item.

links to the above FAQ item, as testing-security is not related to
what the above FAQ-Item says. This may confuse users.

This wiki page also links to the more detailed

  
https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing

which first mentions the unstable-to-testing migration like the FAQ,
but also says:

  Additionally, the http://secure-testing-master.debian.net can issue
  Debian Testing Security Advisories (DTSAs) for packages in the
  testing branch if there is an immediate need to fix a security issue
  in that branch and cannot wait for the normal procedure (or the
  normal procedure is being blocked by some other packages).

  Users willing to take advantage of this support should add the
  following lines to their /etc/apt/sources.list (instead of the
  lines described in Section 4.2, “Execute a security update”):

  deb http://security.debian.org testing/updates main contrib non-free
  # This line makes it possible to donwload source packages too
  deb-src  http://security.debian.org testing/updates main contrib non-free

which is out-of-date: use testing-security instead of the old
testing/updates (this changed in July 2019). This is the following
bug (from July 2019):

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

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Apt sources.list

[Jeffrey Walton]

On Tue, Apr 18, 2023 at 1:46 PM Frank  wrote:
>
> Op 18-04-2023 om 16:33 schreef Vincent Lefevre:
> > On 2023-04-15 21:59:19 +0200, Frank wrote:
> >> Op 15-04-2023 om 18:12 schreef Tixy:
> >>> Testing doesn't get explicit security support so there's no point in
> >>> having 'testing-security' lines in sources.list (I guess it'll give an
> >>> error anyway).
> >>
> >> No error. It exists but as a perpetually empty repository.
> >
> > This is incorrect.
> >
> > cventin:~> apt-show-versions -a libtpms-dev
> > libtpms-dev:amd64 0.9.2-3.1~deb12u1 testing-security security.debian.org
> > No stable version
> > No stable-updates version
> > libtpms-dev:amd64 0.9.2-3.1 testing  ftp.debian.org
> > libtpms-dev:amd64 0.9.2-3.1 unstable ftp.debian.org
> > No experimental version
> > libtpms-dev:amd64 not installed
> > libtpms-dev:i386 0.9.2-3.1~deb12u1 testing-security security.debian.org
> > No stable version
> > No stable-updates version
> > libtpms-dev:i386 0.9.2-3.1 testing  ftp.debian.org
> > libtpms-dev:i386 0.9.2-3.1 unstable ftp.debian.org
> > No experimental version
> > libtpms-dev:i386 not installed
>
> Interesting. Like Tixy, I was under the impression testing didn't
> receive security support. I remember checking that several times over
> the years. Curious.

I did not think so, either. But have a look at
https://www.debian.org/security/faq#testing and
https://wiki.debian.org/DebianTesting .

Jeff

Re: Apt sources.list

[Frank]

Op 18-04-2023 om 16:33 schreef Vincent Lefevre:

On 2023-04-15 21:59:19 +0200, Frank wrote:

Op 15-04-2023 om 18:12 schreef Tixy:

Testing doesn't get explicit security support so there's no point in
having 'testing-security' lines in sources.list (I guess it'll give an
error anyway).


No error. It exists but as a perpetually empty repository.


This is incorrect.

cventin:~> apt-show-versions -a libtpms-dev
libtpms-dev:amd64 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:amd64 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:amd64 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:amd64 not installed
libtpms-dev:i386 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:i386 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:i386 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:i386 not installed


Interesting. Like Tixy, I was under the impression testing didn't 
receive security support. I remember checking that several times over 
the years. Curious.


Regards,
Frank

Re: Apt sources.list

[Vincent Lefevre]

On 2023-04-15 21:59:19 +0200, Frank wrote:
> Op 15-04-2023 om 18:12 schreef Tixy:
> > On Sat, 2023-04-15 at 08:11 -0400, pa...@quillandmouse.com wrote:
> 
> > > According to https://www.debian.org/releases/, bookworm at this time is
> > > "testing". But when the next release comes, bookworm will still be
> > > bookworm, but "testing" will be bookworm "plus". I'd like to follow
> > > testing, regardless of the status of Debian official releases.
> > > 
> > > So... in my sources.list, if I change "bookworm" to "testing", will it
> > > do that, and (other than the instabilities of testing) is there any
> > > liability to it?
> > 
> > Testing doesn't get explicit security support so there's no point in
> > having 'testing-security' lines in sources.list (I guess it'll give an
> > error anyway).
> 
> No error. It exists but as a perpetually empty repository.

This is incorrect.

cventin:~> apt-show-versions -a libtpms-dev
libtpms-dev:amd64 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:amd64 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:amd64 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:amd64 not installed
libtpms-dev:i386 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:i386 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:i386 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:i386 not installed

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Apt sources.list

[Jeffrey Walton]

On Mon, Apr 17, 2023 at 12:45 AM  wrote:
>
> On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote:
>
> [...]
> > > Corporations don't need browser cooperation for Data Loss Prevention
> > > (DLP) (but they already have it). Corporations just run an
> > > interception proxy, like NetSkope. The NetScope Root CA is loaded into
> > > every browser trust store. The application will terminate all traffic,
> > > inspect it, and forward the request if it looks innocuous.
> >
> > To be clear... The NetSkope Root CA is loaded into browsers for
> > computers owned by the corporation. I.e., part of the corporation's
> > standard image.
>
> Heh. You made me search for it in my browser's root CA store ;-)
>
> Anyway, your points are all valid. I do recommend to have a look
> at the browser's default root CA store before saying "you're safe
> with TLS". This is just marketing. TLS is but one tool.

Yeah, I call it the "CA Zoo." The Browsers will let just about anyone
into the store. All you need to do is check the boxes. If interested
in the day-to-day operations, subscribe to Mozilla's
dev-security-policy list at
https://groups.google.com/a/mozilla.org/g/dev-security-policy. It is
where CAs come to join the store.

There are some efforts to reduce the risk from the CA Zoo. For
example, VISA restricts the list as detailed at
https://developer.visa.com/pages/trusted_certifying_authorities .
VISA's list is 41 in size. It is better than the 150+ in Mozilla's and
Chrome's lists.

> Don't get me wrong: I think widespread use of TLS is a Good Thing.
> But going about it as if it was Redemption is paternalistic to the
> point of being counterproductive.
>
> Security is a process, not a product, as Schneier says.

Jeff

Re: Apt sources.list

[tomas]

On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote:

[...]

> > Corporations don't need browser cooperation for Data Loss Prevention
> > (DLP) (but they already have it). Corporations just run an
> > interception proxy, like NetSkope. The NetScope Root CA is loaded into
> > every browser trust store. The application will terminate all traffic,
> > inspect it, and forward the request if it looks innocuous.
> 
> To be clear... The NetSkope Root CA is loaded into browsers for
> computers owned by the corporation. I.e., part of the corporation's
> standard image.

Heh. You made me search for it in my browser's root CA store ;-)

Anyway, your points are all valid. I do recommend to have a look
at the browser's default root CA store before saying "you're safe
with TLS". This is just marketing. TLS is but one tool.

Don't get me wrong: I think widespread use of TLS is a Good Thing.
But going about it as if it was Redemption is paternalistic to the
point of being counterproductive.

Security is a process, not a product, as Schneier says.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Apt sources.list

[Jeffrey Walton]

On Sun, Apr 16, 2023 at 4:52 PM Jeffrey Walton  wrote:
>
> On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall  wrote:
> >
> > On Sat, 15 Apr 2023, Greg Wooledge wrote:
> >
> > > Now, personally I don't feel this is a threat model that I need to
> > > worry about.  I just use plain old http sources at home, and if "They"
> > > learn that I've downloaded rxvt-unicode and mutt, well, good for Them.
> >
> > The thread model I'm most concerned about is local stuff *exporting*
> > data elsewhere.
> >
> > I do understand that there are people in some parts of the world that
> > want to do things that they ought to be allowed to do but their
> > repressive governments are preventing. HTTPS is a useful tool to make
> > that repression harder - but doesn't actually make people safe - if
> > doing something is illegal then it's still illegal even if it's harder
> > for the authorities to detect it.
> >
> > But it's pretty much impossible nowadays to have a "safe" environment at
> > home. Phones, TVs, almost everything, now tries to establish outgoing
> > connections.
> >
> > ESNI, and DNSoHTTPS are on the way to making it almost impossible to
> > keep tabs on this and restrict what is allowed to egress.
> >
> > The only redeeming point is that corporates *need* to do egress
> > filtering - so at the moment the browsers cannot totally block it - and
> > if they did try, there would be the financing to provide a browser that
> > corporates could use that, at least, allowed SNI sniffing and regular
> > DNS.
>
> Corporations don't need browser cooperation for Data Loss Prevention
> (DLP) (but they already have it). Corporations just run an
> interception proxy, like NetSkope. The NetScope Root CA is loaded into
> every browser trust store. The application will terminate all traffic,
> inspect it, and forward the request if it looks innocuous.

To be clear... The NetSkope Root CA is loaded into browsers for
computers owned by the corporation. I.e., part of the corporation's
standard image.

The NetSkope Root CA is _not_part of Mozilla, Chrome, Edge, Opera,
etc., trust store.

(After re-reading, it sounded like I was stating the latter).

Jeff

> The W3C and Browsers have already decided "interception is a valid use
> case." That boat has already sailed. The browsers claim authority
> comes from Priority of Constituencies under the Web Design Principles.
> I argued against it until I was blue in the face. Also see
> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies.
>
> The conspiracy runs even deeper. App developers cannot ask a WebSocket
> for the certificate or public key used to setup the secure channel. If
> an app/JavaScript could get the info, then it could determine the
> connection was intercepted. The browsers don't want app authors
> knowing that because "interception is a valid use case." So the W3C
> and Browsers have baked interception into the model, and then
> neutered/crippled the technologies to ensure the agenda is moved
> forward.
>
> Jeff

Re: Apt sources.list

[Jeffrey Walton]

On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall  wrote:
>
> On Sat, 15 Apr 2023, Greg Wooledge wrote:
>
> > Now, personally I don't feel this is a threat model that I need to
> > worry about.  I just use plain old http sources at home, and if "They"
> > learn that I've downloaded rxvt-unicode and mutt, well, good for Them.
>
> The thread model I'm most concerned about is local stuff *exporting*
> data elsewhere.
>
> I do understand that there are people in some parts of the world that
> want to do things that they ought to be allowed to do but their
> repressive governments are preventing. HTTPS is a useful tool to make
> that repression harder - but doesn't actually make people safe - if
> doing something is illegal then it's still illegal even if it's harder
> for the authorities to detect it.
>
> But it's pretty much impossible nowadays to have a "safe" environment at
> home. Phones, TVs, almost everything, now tries to establish outgoing
> connections.
>
> ESNI, and DNSoHTTPS are on the way to making it almost impossible to
> keep tabs on this and restrict what is allowed to egress.
>
> The only redeeming point is that corporates *need* to do egress
> filtering - so at the moment the browsers cannot totally block it - and
> if they did try, there would be the financing to provide a browser that
> corporates could use that, at least, allowed SNI sniffing and regular
> DNS.

Corporations don't need browser cooperation for Data Loss Prevention
(DLP) (but they already have it). Corporations just run an
interception proxy, like NetSkope. The NetScope Root CA is loaded into
every browser trust store. The application will terminate all traffic,
inspect it, and forward the request if it looks innocuous.

The W3C and Browsers have already decided "interception is a valid use
case." That boat has already sailed. The browsers claim authority
comes from Priority of Constituencies under the Web Design Principles.
I argued against it until I was blue in the face. Also see
https://www.w3.org/TR/html-design-principles/#priority-of-constituencies.

The conspiracy runs even deeper. App developers cannot ask a WebSocket
for the certificate or public key used to setup the secure channel. If
an app/JavaScript could get the info, then it could determine the
connection was intercepted. The browsers don't want app authors
knowing that because "interception is a valid use case." So the W3C
and Browsers have baked interception into the model, and then
neutered/crippled the technologies to ensure the agenda is moved
forward.

Jeff

Re: Apt sources.list

[Tim Woodall]

On Sat, 15 Apr 2023, Greg Wooledge wrote:



Now, personally I don't feel this is a threat model that I need to
worry about.  I just use plain old http sources at home, and if "They"
learn that I've downloaded rxvt-unicode and mutt, well, good for Them.




The thread model I'm most concerned about is local stuff *exporting*
data elsewhere.

I do understand that there are people in some parts of the world that
want to do things that they ought to be allowed to do but their
repressive governments are preventing. HTTPS is a useful tool to make
that repression harder - but doesn't actually make people safe - if
doing something is illegal then it's still illegal even if it's harder
for the authorities to detect it.

But it's pretty much impossible nowadays to have a "safe" environment at
home. Phones, TVs, almost everything, now tries to establish outgoing
connections.

ESNI, and DNSoHTTPS are on the way to making it almost impossible to
keep tabs on this and restrict what is allowed to egress.

The only redeeming point is that corporates *need* to do egress
filtering - so at the moment the browsers cannot totally block it - and
if they did try, there would be the financing to provide a browser that
corporates could use that, at least, allowed SNI sniffing and regular
DNS.

Re: Apt sources.list

[John Hasler]

Frank writes:
> Are you kidding? No way! Unstable is never pushed into testing just
> like that. There are packages that will never move to testing at all!

That's correct.

Immediately after the release Testing and Stable are identical. Unstable
is unchanged.  When the freeze is lifted packages that have been waiting
in Unstable begin to flow into Testing.

Packages that have been bug-free in Unstable for ten days are linked
into Testing provided all dependencies can be met and that no freeze is
in effect.  They are *not* removed from Unstable.  Packages that have
migrated to Testing remain in Unstable until they are replaced by new
uploads.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Apt sources.list

[David Wright]

On Sun 16 Apr 2023 at 07:14:31 (+0200), Frank wrote:
> Op 15-04-2023 om 22:15 schreef Andrew M.A. Cater:
> > On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote:
> > > On Sat 15 Apr 2023 at 16:45:40 +, Andrew M.A. Cater wrote:
> > > 
> > > > I would suggest that you remain on bookworm until bookworm is released 
> > > > as
> > > > stable. At that point (and only then) change bookworm to trixie and 
> > > > carry
> > > > on. As soon as bookworm is released, there will be massive churn.
> > > 
> > > OK. But how is testing one day before the release of bookworm 
> > > significantly
> > > different from trixie a day afterwards?
> > 
> > "Testing" one day before bookworm release -> bookworm.
> > 
> > On release day, bookworm -> "stable", "unstable" -> testing == trixie
> > Trixie is copied, essentially as the kickstarter for new "unstable".
> > "Unstable" == Forky.
> > 
> > The pent up changes that have been waiting while the freeze has been on
> > all come out at once, potentially.
> > 
> > It might not be very much, but it could be a bunch of stuff, size, effects
> > unknown. Bookworm has been frozen-ish since January ...
> 
> Yet if the OP intends to stay with testing, switching now would be
> fine. Or do you seriously believe moving from bookworm (old testing)
> to trixie (new testing) would have a different effect to staying with
> testing while it moves from bookworm to trixie? The flood of packages
> after the freeze ends would be the same either way.

Yes, there's a difference: the changeover date is of your choosing.
(Or, in my case, it would be six changeover dates.)

Cheers,
David.

Re: Apt sources.list

[Frank]

Op 16-04-2023 om 13:12 schreef Andrew M.A. Cater:

Release day when someone pushes the magic switch and the symlinks move :)


[snip]


"Testing" == "Previous contents of Unstable" (== Trixie / Debian 13)


Are you kidding? No way! Unstable is never pushed into testing just like 
that. There are packages that will never move to testing at all!



"Unstable" == Sid == empty /some of the contents of RC-Buggy (some of which 
will == Debian 14 eventually as Forky)


And this doesn't make sense either.

Regards,
Frank

Re: Apt sources.list

[paulf]

On Sat, 15 Apr 2023 20:30:11 -0400
Jeffrey Walton  wrote:

> On Sat, Apr 15, 2023 at 11:09 AM  wrote:
> > On Sat, 15 Apr 2023 14:01:27 +0100
> > Alain D D Williams  wrote:
> > > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > > While we are talking about this, is there any reason why all the
> > > http: should not be https: ?
> > >
> > > I have done this on my own machine without ill effect.
> >
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate"
> > means we'll downgrade your search ranking if you don't use https.)
> > There is otherwise no earthly reason to have an encrypted
> > connection to a web server unless there is some exchange of private
> > information between you and the server.
> >
> > Reading through all of Google's explanations, I've never seen a
> > satisfactory explanation for this change. With that in mind, I
> > believe the Debian gods did the right thing in leaving their web
> > connections "insecure". Though, in truth, the integrity of Debian
> > server contents wouldn't be changed in the slightest whether the
> > connection was encrypted or not.
> 
> The change came after Snowden released his cache of documents and the
> world learned how pervasive snooping is by the US government. There's
> nothing special about the US government, and we know other governments
> were doing it, too.
> 

OMG! The U.S. government spying on people??!! They only have at least
one government agency which does only that-- the NSA. And everyone's
known about this forever.

What's even funnier is Google pushing this change, since there's no
nosier company on Earth than those guys. Their treasure trove of user
data probably rivals the NSA's.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Apt sources.list

[Eduardo M KALINOWSKI]

On 15/04/2023 19:54, davidson wrote:

On Sat, 15 Apr 2023 to...@tuxteam.de wrote:

On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote:

It's nice not to be telling everyone who can sniff a plaintext
connection which packages you are installing,


Without doubt, this is an advantage of a TLS connection. If you
do care about that, here would be one reason.


In case you wish to obscure what software you *install*, but need not
conceal the software you *download*:

  Step one: Make a list of the packages you want, and then augment it
  with as many plausible alternatives and red herrings as you like.

  Step two:
  $ apt-get -d install 

This downloads the packages only, so you can download packages you
will *not* install, along with ones you will. Then install the proper
subset you want installed, without the '-d' option.


This consumes more resources than using TLS, and increased resource 
usage was one the arguments made against the need for TLS everywhere.



--
BOFH excuse #377:

Someone hooked the twisted pair wires into the answering machine.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Apt sources.list

[Andrew M.A. Cater]

On Sun, Apr 16, 2023 at 12:10:33AM -0400, Stefan Monnier wrote:
> > On release day, bookworm -> "stable",
> 
> So far so good.
> 
> > "unstable" -> testing == trixie
> 
> Really?  I thought there was always a delay for packages to move from
> unstable to testing.
> 

Let's try this again because release day is "special" in the sense
that all the links move down.

Release day -1 (with luck, sometime in late May or early June 2023)

"Oldstable" == Buster == Debian 10
"Stable" == Bullseye == Debian 11
"Stable-updates / Stable backports" -> the Bullseye target
"Testing" == Bookworm (== Debian 12) [FROZEN for several months]
"Unstable" == Sid (== Trixie == will be Debian 13)
"Experimental == RC-Buggy" - stuff that's too unstable for Sid / not
targetted for Testing eventually

Release day when someone pushes the magic switch and the symlinks move :)

"Oldoldstable" == Buster == Debian 10
"Oldstable" == Bullseye == Debian 11
"Stable" == Bookworm == Debian 12
"Testing-proposed-updates" is empty because that's been frozen for months
[If there is anything in it, that now becomes stable updates for next
point release for Bookworm]
"Stable backports" for Buster are removed.
"Stable-backports" for Bookworm is created as is a new T-P-U if needed.
"Testing" == "Previous contents of Unstable" (== Trixie / Debian 13)
"Unstable" == Sid == empty /some of the contents of RC-Buggy (some of which 
will == Debian 14 eventually as Forky)
"Experimental == RC-Buggy"

The moves are instantaneous in one sense: once they're done, then the normal 
routine applies and updates intended for Trixie will be placed into Unstable
and then move through downwards from then on.

On release day, essentially Bookworm remains frozen and the codebase doesn't
move again unless getting updates from either debian-security
or stable backports (if that's what people want). No new code goes in at all.

Testing is now an entirely separate distro which should be developing from
now and will be released in ~two years.

Hence the suggestion to ride with Bookworm until release day precisely and
change at that point to Trixie: using the codenames is always preferable
> 
> Stefan
>

All the very best, as ever,

Andy 

Re: Apt sources.list

[tomas]

On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote:

[...]

> What's wrong, Tomas? Don't you want to watch pornographic videos and
> conduct your banking with the same application?

I'm glad I don't have to use the browser for any of those.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Apt sources.list

[Frank]

Op 15-04-2023 om 22:15 schreef Andrew M.A. Cater:

On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote:

On Sat 15 Apr 2023 at 16:45:40 +, Andrew M.A. Cater wrote:


I would suggest that you remain on bookworm until bookworm is released as
stable. At that point (and only then) change bookworm to trixie and carry
on. As soon as bookworm is released, there will be massive churn.


OK. But how is testing one day before the release of bookworm significantly
different from trixie a day afterwards?



"Testing" one day before bookworm release -> bookworm.

On release day, bookworm -> "stable", "unstable" -> testing == trixie
Trixie is copied, essentially as the kickstarter for new "unstable".
"Unstable" == Forky.

The pent up changes that have been waiting while the freeze has been on
all come out at once, potentially.

It might not be very much, but it could be a bunch of stuff, size, effects
unknown. Bookworm has been frozen-ish since January ...


Yet if the OP intends to stay with testing, switching now would be fine. 
Or do you seriously believe moving from bookworm (old testing) to trixie 
(new testing) would have a different effect to staying with testing 
while it moves from bookworm to trixie? The flood of packages after the 
freeze ends would be the same either way.


Regards,
Frank

Re: Apt sources.list

[David Wright]

On Sun 16 Apr 2023 at 00:10:33 (-0400), Stefan Monnier wrote:
> > On release day, bookworm -> "stable",
> 
> So far so good.
> 
> > "unstable" -> testing == trixie
> 
> Really?  I thought there was always a delay for packages to move from
> unstable to testing.

Well, I suppose it gives the naïve user a few days for thinking they
got away with it unscathed.

Cheers,
David.

Re: Apt sources.list

[Stefan Monnier]

> On release day, bookworm -> "stable",

So far so good.

> "unstable" -> testing == trixie

Really?  I thought there was always a delay for packages to move from
unstable to testing.


Stefan

Re: Apt sources.list

[Jeffrey Walton]

On Sat, Apr 15, 2023 at 11:09 AM  wrote:
> On Sat, 15 Apr 2023 14:01:27 +0100
> Alain D D Williams  wrote:
> > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > While we are talking about this, is there any reason why all the
> > http: should not be https: ?
> >
> > I have done this on my own machine without ill effect.
>
> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between you
> and the server.
>
> Reading through all of Google's explanations, I've never seen a
> satisfactory explanation for this change. With that in mind, I believe
> the Debian gods did the right thing in leaving their web connections
> "insecure". Though, in truth, the integrity of Debian server contents
> wouldn't be changed in the slightest whether the connection was
> encrypted or not.

The change came after Snowden released his cache of documents and the
world learned how pervasive snooping is by the US government. There's
nothing special about the US government, and we know other governments
were doing it, too.

I think Snowden accelerated HTTPS adoption or pushed it over the top.
The browsers were interested in encrypting communications for years
because of the "free ISPs". The ones like NetZero that provided no
cost dialup or broadband, but monitored connections and injected
JavaScript into web pages.

Not only did it happen with HTTPS, it also happened in mail protocols.
Google stopped accepting plain text SMTP connections, too.

I think the browsers did a pretty good job of forcing folks to use
encrypted channels. I think it helped secure content for most users.

One size did not fit all. I watched some browser engineers bully folks
on the Web Crypto mailing list pushing the "HTTPS Everywhere" agenda.
One fellow bullied was Mark Watson who tried to argue NetFlix only
needed encrypted comms part of the time (like login and streaming
content). The Google engineers' treatment of folks with non-conforming
viewpoints was awful.

Jeff

Re: Apt sources.list

[Stefan Monnier]

>> Now, personally I don't feel this is a threat model that I need to 
>> worry about.  I just use plain old http sources at home, and if
>> "They" learn that I've downloaded rxvt-unicode and mutt, well, good
>> for Them.
> My understanding is that mandating HTTPS for all connections is supposed
> to make it so that those who might be watching can't treat the choice by
> the user to connect via HTTPS as a sign that the user has something to
> hide, and therefore is worth observing more closely.

My understanding is that the effect has been (in intelligence agencies
around the world) to push the development of attacks/tools that target
the ends of the connections rather than trying to spy on the
connections themselves.


Stefan

Re: Apt sources.list

[davidson]

On Sat, 15 Apr 2023 Greg Wooledge wrote:

On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote:

In case you wish to obscure what software you *install*, but need not
conceal the software you *download*:

 Step one: Make a list of the packages you want, and then augment it
 with as many plausible alternatives and red herrings as you like.

 Step two:
 $ apt-get -d install 

This downloads the packages only, so you can download packages you
will *not* install, along with ones you will. Then install the proper
subset you want installed, without the '-d' option.


I'm at a loss as to what threat model this is supposed to protect
against.


The answer to *that* question was written on the tin.

Instead, you mean to question the existence of actors who *do* care
what some administrator installs, but do not care what they download.

An entirely fair question. Their existence is a logical possibility.
Since you ask, I don't think their presence is inconceivable.

Ritter wrote...

  "It's nice not to be telling everyone who can sniff a plaintext
  connection which packages you are installing"

I consider it an interesting problem.


In the obvious one ("Comrade Davidson has downloaded package A.  Let's
bump up the priority of his surveillance."), downloading flagged package A
*and* possibly-flagged package B is just going to make your situation
worse, not better.


I explicitly stated, twice (both from the start, and at the conclusion
trimmed by you) that the method does NOT apply to such a threat model.

So here you have helpfully provided a hypothetical narrative to
illustrate a point I wished to make extremely clear.


Now, personally I don't feel this is a threat model that I need to
worry about.  I just use plain old http sources at home, and if
"They" learn that I've downloaded rxvt-unicode and mutt, well, good
for Them.


We do not seem to be having an argument.

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

Re: Apt sources.list

[The Wanderer]

On 2023-04-15 at 19:11, Greg Wooledge wrote:

> On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote:
> 
>> In case you wish to obscure what software you *install*, but need
>> not conceal the software you *download*:
>> 
>> Step one: Make a list of the packages you want, and then augment
>> it with as many plausible alternatives and red herrings as you
>> like.
>> 
>> Step two: $ apt-get -d install 
>> 
>> This downloads the packages only, so you can download packages you 
>> will *not* install, along with ones you will. Then install the
>> proper subset you want installed, without the '-d' option.
> 
> I'm at a loss as to what threat model this is supposed to protect
> against.

My guess is that it's supposed to make it harder for people to guess
what exploits your computer may be vulnerable to, by obfuscating which
of the various packages you downloaded are actually installed and
therefore potentially in use.



> Now, personally I don't feel this is a threat model that I need to 
> worry about.  I just use plain old http sources at home, and if
> "They" learn that I've downloaded rxvt-unicode and mutt, well, good
> for Them.

My understanding is that mandating HTTPS for all connections is supposed
to make it so that those who might be watching can't treat the choice by
the user to connect via HTTPS as a sign that the user has something to
hide, and therefore is worth observing more closely.

I seem to remember having seen suggestions that some regimes might even
prohibit the use of HTTPS entirely, so as to ensure that they can spy on
their subjects' connections, and that such a prohibition would be less
practical for them to impose if everything requires HTTPS. I'm not sure
about the real-world basis for that, however.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Apt sources.list

[Greg Wooledge]

On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote:
> In case you wish to obscure what software you *install*, but need not
> conceal the software you *download*:
> 
>  Step one: Make a list of the packages you want, and then augment it
>  with as many plausible alternatives and red herrings as you like.
> 
>  Step two:
>  $ apt-get -d install 
> 
> This downloads the packages only, so you can download packages you
> will *not* install, along with ones you will. Then install the proper
> subset you want installed, without the '-d' option.

I'm at a loss as to what threat model this is supposed to protect against.
In the obvious one ("Comrade Davidson has downloaded package A.  Let's
bump up the priority of his surveillance."), downloading flagged package A
*and* possibly-flagged package B is just going to make your situation
worse, not better.

Now, personally I don't feel this is a threat model that I need to
worry about.  I just use plain old http sources at home, and if "They"
learn that I've downloaded rxvt-unicode and mutt, well, good for Them.

Re: Apt sources.list

[davidson]

On Sat, 15 Apr 2023 to...@tuxteam.de wrote:

On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote:

pa...@quillandmouse.com wrote:


Okay. Let's open this can of worms.


I wish more would.


The ONLY reason https is used on most sites is because Google
*mandated* it years ago. ("Mandate" means we'll downgrade your
search ranking if you don't use https.) There is otherwise no
earthly reason to have an encrypted connection to a web server
unless there is some exchange of private information between you
and the server.


... and because Let's Encrypt made it relatively easy, monetarily
free, and automated.


Who doesn't love free tickets to the security theatre?


Google Chrome being one of their sponsors.

Now don't get me wrong: there are many things to like about TLS in
general and about Let's Encrypt in particular. And another sponsor
of Let's Encrypt is the EFF, whose motives, to me at least, are
beyond reproach.


That the EFF is "beyond reproach" is quite a strong statement. Once
upon a time, I would have agreed.

I am no longer so confident. Institutions that pose a genuine threat
(to the agenda of the powers that be) get captured. One must seek out
and examine evidence that contradicts beliefs that make one feel safe.

Placing an institution "beyond reproach" prevents that practice.


But it's a mixed bag, and that "unencrypted is BAAAD" meme is just
security theater.


Security theatre is never cost-free, and always has a purpose. Whose
purpose? Who pays for it? And who endorsed propaganda in favor of its
institution?


"insecure". Though, in truth, the integrity of Debian server contents
wouldn't be changed in the slightest whether the connection was
encrypted or not.



It's nice not to be telling everyone who can sniff a plaintext
connection which packages you are installing,


Without doubt, this is an advantage of a TLS connection. If you
do care about that, here would be one reason.


In case you wish to obscure what software you *install*, but need not
conceal the software you *download*:

 Step one: Make a list of the packages you want, and then augment it
 with as many plausible alternatives and red herrings as you like.

 Step two:
 $ apt-get -d install 

This downloads the packages only, so you can download packages you
will *not* install, along with ones you will. Then install the proper
subset you want installed, without the '-d' option.

This is more work *for you* than TLS (supposing you don't automate
alternative/red-herring selection). More work for you may be worth the
cost, if the work is effective. This method does not rely on
certificates and "trusted" authorities.

As already mentioned, it does not prevent observers from noticing that
you *downloaded* something forbidden.


and prevents those people from trivially substituting trojan
horses.


Setting aside the question of what class of actors are (or are not) so
thwarted, I was surprised to read this. A clarification or elaboration
might be interesting.

Sufficient clarity and necessary precision often work against one
another.


...and this is downright wrong.


Or perhaps incomplete. I too did a double-take, though, and would like
to hear more.


The Debian packages are signed.


Q: Waaah. Stupid APT won't verify a key.
A: Easy peasy. [Demonstrates how to retrieve and trust attacker's key]
Q: Thanks a lot, anon. It worked!


 If you got your first install from a trusted source, this is way
more secure than TLS [1]. TLS doesn't hurt here, but it doesn't help
much, either.

[1] Have you ever had a look at the incredible zoo of root certs
your browser trusts?


What's wrong, Tomas? Don't you want to watch pornographic videos and
conduct your banking with the same application?

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

Re: Apt sources.list

[songbird]

Andrew M.A. Cater wrote:
...
> On release day, bookworm -> "stable", "unstable" -> testing == trixie
> Trixie is copied, essentially as the kickstarter for new "unstable".
> "Unstable" == Forky. 

  Unstable == Sid  Forky will happen sometime in the future
when they start talking about freezing testing again.


  songbird

Re: Apt sources.list

[Andrew M.A. Cater]

On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote:
> On Sat 15 Apr 2023 at 16:45:40 +, Andrew M.A. Cater wrote:
> 
> > I would suggest that you remain on bookworm until bookworm is released as
> > stable. At that point (and only then) change bookworm to trixie and carry
> > on. As soon as bookworm is released, there will be massive churn.
> 
> OK. But how is testing one day before the release of bookworm significantly
> different from trixie a day afterwards?
> 

"Testing" one day before bookworm release -> bookworm.

On release day, bookworm -> "stable", "unstable" -> testing == trixie
Trixie is copied, essentially as the kickstarter for new "unstable".
"Unstable" == Forky. 

The pent up changes that have been waiting while the freeze has been on
all come out at once, potentially.

It might not be very much, but it could be a bunch of stuff, size, effects
unknown. Bookworm has been frozen-ish since January ...

It's as nothing to the "feels larger" shock to people who keep their 
Debian pinned to "stable" and suddenly get ~2.2 years worth of (possibly
incompatible) changes in a day, however, and then wonder what hit them.

All best, as ever,

Andy Cater

All best, as ever

> -- 
> Brian.
> 

Re: Apt sources.list

[paulf]

On Sat, 15 Apr 2023 16:45:40 +
"Andrew M.A. Cater"  wrote:

> On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote:
> > 
> > > Folks:
> > > 
> > > Here is my sources.list file:
> > > 
> > > ---
> > > 
> > > deb http://debian.uchicago.edu/debian/ bookworm main contrib
> > > non-free deb-src http://debian.uchicago.edu/debian/ bookworm main
> > > contrib non-free
> > > 
> > > deb http://security.debian.org/debian-security bookworm-security
> > > main contrib non-free deb-src
> > > http://security.debian.org/debian-security bookworm-security main
> > > contrib non-free
> > > 
> > > ---
> > > 
> > > According to https://www.debian.org/releases/, bookworm at this
> > > time is "testing". But when the next release comes, bookworm will
> > > still be bookworm, but "testing" will be bookworm "plus". I'd
> > > like to follow testing, regardless of the status of Debian
> > > official releases.
> > > 
> 
> I would really not advise that. The changes as one distribution rolls
> to stable and the next one becomes testing are quite major - also,
> things change (like sources.list files).
> 
> I would suggest that you remain on bookworm until bookworm is
> released as stable. At that point (and only then) change bookworm to
> trixie and carry on. As soon as bookworm is released, there will be
> massive churn.
> 
> Stable, testing, unstable are mutable: distribution code names are
> not. There's a reason why Debian switched to codenames early - there
> never was a Debian 1.0 -
> https://en.wikipedia.org/wiki/Debian_version_history and
> https://wiki.debian.org/DebianReleases
> 

I've been at Debian for a couple of decades now, and I'm aware of how
the distro and its flavors change periodically. At the instant bookworm
becomes "official", stable changes completely to become bookworm, and
testing is slightly different from bookworm. I've run stable, testing
and sid in the past. Sid's a little too unstable for my tastes. But
stable is typically too "old". Testing is fine for me as long as I
don't continually update packages.

A while back, I tried Arch for about four months. Great distro, but I
had stability problems because on Arch, you typically update all the
time. It's a complete moving target. It's fine for a lot of guys who
chase the latest packages, but I'm not that guy.

When Debian officially changes versions, I typically reinstall, whether
I'm running stable or testing. This brings most everything up to date,
and eliminates the cruft I'm accumulated of packages I installed but no
longer want. 

I'm willing to shoulder the risks of running testing and upgrading
entirely when bookworm becomes stable.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Apt sources.list

[Frank]

Op 15-04-2023 om 18:12 schreef Tixy:

On Sat, 2023-04-15 at 08:11 -0400, pa...@quillandmouse.com wrote:



According to https://www.debian.org/releases/, bookworm at this time is
"testing". But when the next release comes, bookworm will still be
bookworm, but "testing" will be bookworm "plus". I'd like to follow
testing, regardless of the status of Debian official releases.

So... in my sources.list, if I change "bookworm" to "testing", will it
do that, and (other than the instabilities of testing) is there any
liability to it?


Testing doesn't get explicit security support so there's no point in
having 'testing-security' lines in sources.list (I guess it'll give an
error anyway).


No error. It exists but as a perpetually empty repository.

Regards,
Frank

Re: Apt sources.list

[Andy Smith]

On Sat, Apr 15, 2023 at 07:21:17PM +0100, Alain D D Williams wrote:
> On Sat, Apr 15, 2023 at 11:00:52AM -0400, pa...@quillandmouse.com wrote:
> 
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate" means
> > we'll downgrade your search ranking if you don't use https.) There is
> > otherwise no earthly reason to have an encrypted connection to a web
> > server unless there is some exchange of private information between you
> > and the server.
> 
> Where I live (England) I do not care if "the authorities" see what I have
> installed on my machine. If I lived in a totalitarian state†† there are some
> packages that might raise my profile on some "radar".

I am sad to have to type such an obvious point, but the https
feature exists for everyone, not just you. It is great that you are
privileged enough to not feel like you are under threat from your
own government (whether you have accurately estimated that risk is
another conversation) but not everyone is so privileged.

You did not ask if the feature made sense *for you*, you just asked
about the feature. Even if you *had* asked if it made sense for you,
no one would be able to answer as only you can decide what your
threat model is.

What you have said above is almost literally, "I don't have anything
to hide therefore I don't need privacy", but you've said it in such
a way as to imply that no one needs this particular feature.
Disappointing.

Your literal question was if there was any reason NOT to change
every APT URL to https. The objective answer is that not all Debian
mirrors support https! It seems like your real question was more
like, "is there any point to doing this" which you got a lot of
response to.

The hiding of the content of what is requested is a real feature
that some people want.

I haven't yet seen it mentioned in this thread but there are even
people who refute that argument. They say that an advanced attacker
in the middle will use traffic analysis and the publicly known sizes
of all Debian packages to easily work out which packages are
requested even without their names being visible.

Still, it not being in the clear makes this harder, and some people
want that.

By the way, in terms of malware distribution it is easier to
compromise a real Debian developer and get them to upload the bad
package in an entirely proper way. THis has already happened at
least once, though not to a stable release AFAIK. Unlike tampering
of in-flight downloads which has never been reported.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting


signature.asc
Description: PGP signature

Re: Apt sources.list

[Charles Curley]

On Sat, 15 Apr 2023 11:00:52 -0400
 wrote:

> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between
> you and the server.

 I disagree. If everyone only encrypted the traffic they wanted kept
 private, the bad guys would know that decrypting a stream would yield
 sensitive information. If we all encrypt a lot of our traffic,
 sensitive and otherwise, we reduce the advantage of cracking encrypted
 traffic.

There is no such thing as absolute security. There is only relative
security. The object, then, is to make yourself more secure than other
people. The bad guys will leave you alone and go after easier pickings.
Of course, the easier pickings should wise up and up their game as
well, leading to a nice virtuous spiral.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Apt sources.list

[Alain D D Williams]

On Sat, Apr 15, 2023 at 11:00:52AM -0400, pa...@quillandmouse.com wrote:

> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between you
> and the server.

Where I live (England) I do not care if "the authorities" see what I have
installed on my machine. If I lived in a totalitarian state†† there are some
packages that might raise my profile on some "radar".

†† There are several - I will not mention names as I wish to keep politics out
of this list.

> Reading through all of Google's explanations, I've never seen a
> satisfactory explanation for this change. With that in mind, I believe
> the Debian gods did the right thing in leaving their web connections
> "insecure". Though, in truth, the integrity of Debian server contents
> wouldn't be changed in the slightest whether the connection was
> encrypted or not.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Apt sources.list

[tomas]

On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote:
> pa...@quillandmouse.com wrote: 
> > 
> > Okay. Let's open this can of worms. The ONLY reason https is used on
> > most sites is because Google *mandated* it years ago. ("Mandate" means
> > we'll downgrade your search ranking if you don't use https.) There is
> > otherwise no earthly reason to have an encrypted connection to a web
> > server unless there is some exchange of private information between you
> > and the server.
> 
> ... and because Let's Encrypt made it relatively easy,
> monetarily free, and automated.

Google Chrome being one of their sponsors.

Now don't get me wrong: there are many things to like about TLS in
general and about Let's Encrypt in particular. And another sponsor
of Let's Encrypt is the EFF, whose motives, to me at least, are
beyond reproach. But it's a mixed bag, and that "unencrypted is
BAAAD" meme is just security theater.

> > "insecure". Though, in truth, the integrity of Debian server contents
> > wouldn't be changed in the slightest whether the connection was
> > encrypted or not.
> 
> 
> It's nice not to be telling everyone who can sniff a plaintext
> connection which packages you are installing,

Without doubt, this is an advantage of a TLS connection. If you
do care about that, here would be one reason.

>and prevents those
> people from trivially substituting trojan horses.

...and this is downright wrong. The Debian packages are signed.
If you got your first install from a trusted source, this is
way more secure than TLS [1]. TLS doesn't hurt here, but it
doesn't help much, either.

[1] Have you ever had a look at the incredible zoo of root certs
your browser trusts?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Apt sources.list

[Andrew M.A. Cater]

On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote:
> 
> > Folks:
> > 
> > Here is my sources.list file:
> > 
> > ---
> > 
> > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > 
> > deb http://security.debian.org/debian-security bookworm-security main
> > contrib non-free deb-src http://security.debian.org/debian-security 
> > bookworm-security main contrib non-free
> > 
> > ---
> > 
> > According to https://www.debian.org/releases/, bookworm at this time is
> > "testing". But when the next release comes, bookworm will still be
> > bookworm, but "testing" will be bookworm "plus". I'd like to follow
> > testing, regardless of the status of Debian official releases.
> > 

I would really not advise that. The changes as one distribution rolls to 
stable and the next one becomes testing are quite major - also, things
change (like sources.list files).

I would suggest that you remain on bookworm until bookworm is released as
stable. At that point (and only then) change bookworm to trixie and carry
on. As soon as bookworm is released, there will be massive churn.

Stable, testing, unstable are mutable: distribution code names are not.
There's a reason why Debian switched to codenames early - there never was
a Debian 1.0 - https://en.wikipedia.org/wiki/Debian_version_history
and https://wiki.debian.org/DebianReleases

With every good wish, as ever,

Andy Cater
> > So... in my sources.list, if I change "bookworm" to "testing", will it
> > do that, and (other than the instabilities of testing) is there any
> > liability to it?
> 
> bookworm to testing is exactly what you want.
> 
> -- 
> Brian.
> 

Re: Apt sources.list

[Dan Ritter]

pa...@quillandmouse.com wrote: 
> 
> Okay. Let's open this can of worms. The ONLY reason https is used on
> most sites is because Google *mandated* it years ago. ("Mandate" means
> we'll downgrade your search ranking if you don't use https.) There is
> otherwise no earthly reason to have an encrypted connection to a web
> server unless there is some exchange of private information between you
> and the server.

... and because Let's Encrypt made it relatively easy,
monetarily free, and automated.


> "insecure". Though, in truth, the integrity of Debian server contents
> wouldn't be changed in the slightest whether the connection was
> encrypted or not.


It's nice not to be telling everyone who can sniff a plaintext
connection which packages you are installing, and prevents those
people from trivially substituting trojan horses.

-dsr-

Re: Apt sources.list

[Tixy]

On Sat, 2023-04-15 at 08:11 -0400, pa...@quillandmouse.com wrote:
> Folks:
> 
> Here is my sources.list file:
> 
> ---
> 
> deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> 
> deb http://security.debian.org/debian-security bookworm-security main
> contrib non-free deb-src http://security.debian.org/debian-security 
> bookworm-security main contrib non-free
> 
> ---
> 
> According to https://www.debian.org/releases/, bookworm at this time is
> "testing". But when the next release comes, bookworm will still be
> bookworm, but "testing" will be bookworm "plus". I'd like to follow
> testing, regardless of the status of Debian official releases.
> 
> So... in my sources.list, if I change "bookworm" to "testing", will it
> do that, and (other than the instabilities of testing) is there any
> liability to it?

Testing doesn't get explicit security support so there's no point in
having 'testing-security' lines in sources.list (I guess it'll give an
error anyway).

-- 
Tixy

Re: Apt sources.list

[paulf]

On Sat, 15 Apr 2023 14:01:27 +0100
Alain D D Williams  wrote:

> On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> > On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > > On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com
> > > wrote:
> > > > ---
> > > > 
> > > > deb http://debian.uchicago.edu/debian/ bookworm main contrib
> > > > non-free deb-src http://debian.uchicago.edu/debian/ bookworm
> > > > main contrib non-free
> > > > 
> > > > deb http://security.debian.org/debian-security
> > > > bookworm-security main contrib non-free deb-src
> > > > http://security.debian.org/debian-security bookworm-security
> > > > main contrib non-free
> > > > 
> > > > ---
> 
> While we are talking about this, is there any reason why all the
> http: should not be https: ?
> 
> I have done this on my own machine without ill effect.
> 

Okay. Let's open this can of worms. The ONLY reason https is used on
most sites is because Google *mandated* it years ago. ("Mandate" means
we'll downgrade your search ranking if you don't use https.) There is
otherwise no earthly reason to have an encrypted connection to a web
server unless there is some exchange of private information between you
and the server.

Reading through all of Google's explanations, I've never seen a
satisfactory explanation for this change. With that in mind, I believe
the Debian gods did the right thing in leaving their web connections
"insecure". Though, in truth, the integrity of Debian server contents
wouldn't be changed in the slightest whether the connection was
encrypted or not.

Paul


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Apt sources.list

[Charles Curley]

On Sat, 15 Apr 2023 14:01:27 +0100
Alain D D Williams  wrote:

> While we are talking about this, is there any reason why all the
> http: should not be https: ?
> 
> I have done this on my own machine without ill effect.

One reason is if one is using a local cache which does not inspect
https streams. Last I knew, such local caches included apt-cacher-ng.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Apt sources.list

[paulf]

On Sat, 15 Apr 2023 13:23:05 +0100
Brian  wrote:

> On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote:
> 
> > Folks:
> > 
> > Here is my sources.list file:
> > 
> > ---
> > 
> > deb http://debian.uchicago.edu/debian/ bookworm main contrib
> > non-free deb-src http://debian.uchicago.edu/debian/ bookworm main
> > contrib non-free
> > 
> > deb http://security.debian.org/debian-security bookworm-security
> > main contrib non-free deb-src
> > http://security.debian.org/debian-security bookworm-security main
> > contrib non-free
> > 
> > ---
> > 
> > According to https://www.debian.org/releases/, bookworm at this
> > time is "testing". But when the next release comes, bookworm will
> > still be bookworm, but "testing" will be bookworm "plus". I'd like
> > to follow testing, regardless of the status of Debian official
> > releases.
> > 
> > So... in my sources.list, if I change "bookworm" to "testing", will
> > it do that, and (other than the instabilities of testing) is there
> > any liability to it?
> 
> bookworm to testing is exactly what you want.
> 

Thanks for your advice. I ran apt update with no issues.

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Apt sources.list

[tomas]

On Sat, Apr 15, 2023 at 02:59:49PM +0100, Alain D D Williams wrote:
> On Sat, Apr 15, 2023 at 03:48:31PM +0200, to...@tuxteam.de wrote:
> > On Sat, Apr 15, 2023 at 02:01:27PM +0100, Alain D D Williams wrote:
> > 
> > [...]
> > 
> > > While we are talking about this, is there any reason why all the http: 
> > > should
> > > not be https: ?
> > 
> > It's just unnecessary CPU on the server, that's all.
> 
> That used to be the case many years ago. Modern CPUs have instructions that
> make it much quicker.

It may be /less/ than it used to be (what would interest me
is the overall energy consumption, joules/megabyte or so).
But it is nonzero.

And still, it's unnecessary.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Apt sources.list

[Alain D D Williams]

On Sat, Apr 15, 2023 at 03:48:31PM +0200, to...@tuxteam.de wrote:
> On Sat, Apr 15, 2023 at 02:01:27PM +0100, Alain D D Williams wrote:
> 
> [...]
> 
> > While we are talking about this, is there any reason why all the http: 
> > should
> > not be https: ?
> 
> It's just unnecessary CPU on the server, that's all.

That used to be the case many years ago. Modern CPUs have instructions that
make it much quicker.

"On our production frontend machines, SSL/TLS accounts for less than 1% of the
CPU load, less than 10 KB of memory per connection and less than 2% of network
overhead."

https://istlsfastyet.com/

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Apt sources.list

[tomas]

On Sat, Apr 15, 2023 at 02:01:27PM +0100, Alain D D Williams wrote:

[...]

> While we are talking about this, is there any reason why all the http: should
> not be https: ?

It's just unnecessary CPU on the server, that's all.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Apt sources.list

[Alain D D Williams]

On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote:
> On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> > On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote:
> > > ---
> > > 
> > > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > > 
> > > deb http://security.debian.org/debian-security bookworm-security main
> > > contrib non-free deb-src http://security.debian.org/debian-security 
> > > bookworm-security main contrib non-free
> > > 
> > > ---

While we are talking about this, is there any reason why all the http: should
not be https: ?

I have done this on my own machine without ill effect.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Apt sources.list

[Greg Wooledge]

On Sat, Apr 15, 2023 at 01:23:05PM +0100, Brian wrote:
> On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote:
> > ---
> > 
> > deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> > 
> > deb http://security.debian.org/debian-security bookworm-security main
> > contrib non-free deb-src http://security.debian.org/debian-security 
> > bookworm-security main contrib non-free
> > 
> > ---

> > I'd like to follow
> > testing, regardless of the status of Debian official releases.

> bookworm to testing is exactly what you want.

That, and adding the non-free-firmware section.

https://wiki.debian.org/NewInBookworm

Re: Apt sources.list

[Brian]

On Sat 15 Apr 2023 at 08:11:17 -0400, pa...@quillandmouse.com wrote:

> Folks:
> 
> Here is my sources.list file:
> 
> ---
> 
> deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free
> 
> deb http://security.debian.org/debian-security bookworm-security main
> contrib non-free deb-src http://security.debian.org/debian-security 
> bookworm-security main contrib non-free
> 
> ---
> 
> According to https://www.debian.org/releases/, bookworm at this time is
> "testing". But when the next release comes, bookworm will still be
> bookworm, but "testing" will be bookworm "plus". I'd like to follow
> testing, regardless of the status of Debian official releases.
> 
> So... in my sources.list, if I change "bookworm" to "testing", will it
> do that, and (other than the instabilities of testing) is there any
> liability to it?

bookworm to testing is exactly what you want.

-- 
Brian.

Apt sources.list

[paulf]

Folks:

Here is my sources.list file:

---

deb http://debian.uchicago.edu/debian/ bookworm main contrib non-free
deb-src http://debian.uchicago.edu/debian/ bookworm main contrib non-free

deb http://security.debian.org/debian-security bookworm-security main
contrib non-free deb-src http://security.debian.org/debian-security 
bookworm-security main contrib non-free

---

According to https://www.debian.org/releases/, bookworm at this time is
"testing". But when the next release comes, bookworm will still be
bookworm, but "testing" will be bookworm "plus". I'd like to follow
testing, regardless of the status of Debian official releases.

So... in my sources.list, if I change "bookworm" to "testing", will it
do that, and (other than the instabilities of testing) is there any
liability to it?

Paul


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: About /etc/apt/sources.list | Warehouse for users of the stable version

[Cindy Sue Causey]

On 11/23/22, 谢 运生  wrote:
> Dear  Debian,
>
> I have a question about stabilizing the warehouse:
>
> https://www.debian.org/doc/manuals/debian-handbook/apt.zh-cn.html#sect.apt-sources.list.stable
>
> Four bullseye are mentioned in this link, Would it make any difference if
> only bullseye and bullsey-updates were added to /etc/apt/sources.list and he
> added all four bullseys to /etc/apt/sources.list at the same time?
>
> Please give me some of your professional advice.


Hi.. This is my second attempt to help answer, LOL. After looking at
your link there AND if I'm understanding your question correctly, you
want to have at least 3 lines that include debian-security, too. I
didn't know nor do that for many years. It came up here on Debian-User
one day. Some number of security updates do NOT upgrade if that's not
in your sources.list. I experienced that firsthand as a fact but could
never figure out why until someone asked on this list (Thank you!)..

The debian-backports one is for situations where your favorite package
is not included in the others but can be found there after you've
researched availability. I happen to use the debian-backports one
after finally understanding its concept. At some point, I installed
something from there so it was a necessary inclusion to stay
up-to-date. These days I just keep it in the lineup to always remember
that it's an option. :)

The "Debian mirror" references is a nice reminder that you can
reference other repositories in addition to those housed at
debian(dot)org. You can addend those mirrors to that same single
sources.list file, or you can research how to add additional files
under sources.list.d. That dot D directory is a handy trick that
taught me the purpose of other similar directories found throughout
our systems if we're using the systemd setup.

These two links share mirror examples. The second one is getting a
mention because it takes another step up and explicitly states useful
specifics e.g. ibiblio:

https://www.debian.org/mirror/list

https://people.debian.org/~koster/www/mirror/list

It doesn't hurt to have those in mind in case a favored first choice
repository happens to be down when a user is in a hurry to update for
whatever reason.

As an aside, that "bullseye-proposed-updates" looks interesting. Never
saw that before. Will be checking it out. Thank you!

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: About /etc/apt/sources.list | Warehouse for users of the stable version

[Thomas Schmitt]

Hi,

c0ldz...@outlook.com wrote:
> I have a question about stabilizing the warehouse:
> https://www.debian.org/doc/manuals/debian-handbook/apt.zh-cn.html#sect.apt-sources.list.stable

Most of us are probably not educated enough to cope with a chinese language
site. So i propose that we discuss the original english language version
  
https://www.debian.org/doc/manuals/debian-handbook/apt.html#sect.apt-sources.list.stable

I guess that with "warehouse" you mean what the english site mentions as
"repository".


> Four bullseye are mentioned in this link,

I see only two lines which refer to "bullseye" without a suffix like
"-security":

  # Base repository
  deb https://deb.debian.org/debian bullseye main contrib non-free
  deb-src https://deb.debian.org/debian bullseye main contrib non-free

The "deb" line is for getting binary packages. The "deb-src" line is
for the source packages, which a normal user will use only when being
quite curious. (I rather quench my curiosity by looking at URLs like
  https://sources.debian.org/src/libisofs/1.5.4-1/
which are published by the packages' tracker pages like
  https://tracker.debian.org/pkg/libisofs
as "browse source code" to the right under the title "links".)


> Would it make any difference if
> only bullseye and bullsey-updates were added to /etc/apt/sources.list and he
> added all four bullseys to /etc/apt/sources.list at the same time?

I guess that this sentence fell victim to automatic translation and that
the "and he" is the separator between two alternatives.
I.e. the question would be whether omitting bullseye-security and
bullseye-backports makes a difference.

If so, then the answer is that bullseye-security is for important bug
fixes which should generally be installed as soon as they are available.
So i would say that omitting it makes an important and dangerous difference.

bullseye-backports is only for users who want to use certain packages
from the current "Testing" version of Debian. Omitting it should not hamper
normal use and administration of a Debian GNU/Linux system.

The paragraphs 6.1.2.1. to 6.1.2.4. explain the purpose of the various
bullseye-* repositories.

If the chinese translation is unclear, then the question changes to:
  How can i contact the handbook translators ?
Looking at the german translation's intro page
  https://www.debian.org/doc/manuals/debian-handbook/index.de.html
i find no hint.
At
  
https://debian-handbook.info/2012/translating-the-debian-administrators-handbook/
i find the mailing list address
  debian-handbook-translat...@alioth-lists.debian.net
of which the archive shows some activity
  https://alioth-lists.debian.net/pipermail/debian-handbook-translators/


Have a nice day :)

Thomas

About /etc/apt/sources.list | Warehouse for users of the stable version

[谢 运生]

Dear  Debian,

I have a question about stabilizing the warehouse:

https://www.debian.org/doc/manuals/debian-handbook/apt.zh-cn.html#sect.apt-sources.list.stable

Four bullseye are mentioned in this link, Would it make any difference if only 
bullseye and bullsey-updates were added to /etc/apt/sources.list and he added 
all four bullseys to /etc/apt/sources.list at the same time?

Please give me some of your professional advice.

Thank!

Best Regards,

- Yunsheng Xie
Email: c0ldz...@outlook.com

Re: xterm. Valid /etc/apt/sources.list [Was 26th pass]

[Andrew M.A. Cater]

On Sun, Jun 12, 2022 at 08:08:49AM -0400, Greg Wooledge wrote:
> On Sun, Jun 12, 2022 at 07:53:21AM -0400, gene heskett wrote:
> > gene@coyote:~$ bash: xterm: command not found
> > 
> > xterm cannot be found by synaptic or apt either.
> 
> unicorn:~$ apt policy xterm
> xterm:
>   Installed: 366-1+deb11u1
>   Candidate: 366-1+deb11u1
>   Version table:
>  *** 366-1+deb11u1 500
> 500 http://ftp.us.debian.org/debian bullseye/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> Your sources are broken, Gene.
> 
> > So I'll repeat, what is this magic xterm? What do I install to get it?
> 
> You don't need to run xterm specifically.  You can use any freaking
> terminal.
> 
> That should have been obvious to anyone who's been running Linux as
> long as you have.
> 
> However, now we have a claim that in addition to all your *other* problems,
> you have broken Debian sources on at least one of your systems.  No
> actual *proof*, mind you.  Just a claim.
> 
> Or... is it even Debian?  Hell.  It's probably not.  It's probably
> your heavily customized version of Raspbian that only a dozen people on
> Earth use.
>

Gene

Cat /etc/apt/sources.list

Check that it doesn't _only_ have non-networked sources / that everything
has been commented out with a # if you weren't validly on a network to 
start with.

Mine looks something like this:

deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye main contrib non-free

deb http://security.debian.org/debian-security bullseye-security main contrib 
non-free
deb-src http://security.debian.org/debian-security bullseye-security main 
contrib non-free
 
# bullseye-update, to get updates before a point release is made:
# see 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports

deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free

A couple of wrapped lines but you should be able to figure it out else

https://wiki.debian.org/SourcesList

Hope this helps

Andy Cater

Re: what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[Andy Smith]

Hi Evelyn,

On Sun, Aug 15, 2021 at 06:00:08PM +0200, Evelyn Pereira Souza wrote:
> E: The repository 'http://security.debian.org/debian-security
> bullseye/updates Release' does not have a Release file.

A few people have by now pointed out the specific cause of your
problem, but the root cause is that you've done an update to the
next version of Debian without reading the release notes. You always
need to read the release notes, every time, not just for bullseye.


https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html

As you can see there are a number of other issues there. There
usually are. So save yourself some frustration by reading the
release notes every time.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting


signature.asc
Description: PGP signature

Re: what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[Michael Grant]

> deb http://security.debian.org/debian-security bullseye/updates main contrib
> non-free
> deb-src http://security.debian.org/debian-security bullseye/updates main
> contrib non-free

I think you are missing bullseye-security.  I have this:

deb http://mirrors.linode.com/debian-security/ bullseye-security main 
contrib non-free
deb-src http://mirrors.linode.com/debian-security/ bullseye-security main 
contrib non-free

I'm not so sure I need the 'contrib non-free' at the end of the line
but it's not giving me any errors.




signature.asc
Description: PGP signature

Re: what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[tomas]

On Sun, Aug 15, 2021 at 12:06:18PM -0400, The Wanderer wrote:
> On 2021-08-15 at 12:00, Evelyn Pereira Souza wrote:
> 
> > Hi
> > 
> > apt-get update
> > Ign:1 http://security.debian.org/debian-security bullseye/updates InRelease
> > Err:2 http://security.debian.org/debian-security bullseye/updates Release
> >404  Not Found [IP: 199.232.138.132 80]
> 
> > deb http://security.debian.org/debian-security bullseye/updates main 
> > contrib non-free
> 
> This 'suite/updates' syntax is apparently no longer correct for
> security.debian.org.
> 
> I'm not familiar with the use of this 'debian-security' affix on the
> repository URL, but for comparison, my own sources.list now has:
> 
> deb http://security.debian.org/ testing-security main contrib non-free

Someone helpfully posted that in this list, not long ago:

  "NOTE Layout of security repositories

   Starting with Debian 11 Bullseye, the codename of the repository
   providing security updates has been renamed from codename/updates
   into codename-security to avoid the confusion with codename-updates
   (see Section 6.1.2.2, 'Stable Updates')." [1]

So at least, the 'bullseye/updates' to the right of the URL should, at least,
be 'bullseye-security, as you noted, Wanderer.

> and I'm not getting this 404 anymore.
> 
> You might try something analogous (probably with 'bullseye-security') in
> place of 'bullseye/updates', and see whether it helps.

So it seems to be intentional.

Cheers
[1] 
https://debian-handbook.info/browse/en-US/stable/apt.html#sect.apt-sources.list.testing
 - t


signature.asc
Description: Digital signature

Re: what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[Hans]

Am Sonntag, 15. August 2021, 18:00:08 CEST schrieb Evelyn Pereira Souza:
Hi Evelyn, 

the entry in sources.list has changed, it is now:

deb http://deb.debian.org/debian-security bullseye-security main contrib 
non-free 
deb-src http://deb.debian.org/debian-security bullseye-security main contrib 
non-free

Hope this helps.

Best regards

Hans

> Hi
> 
> apt-get update
> Ign:1 http://security.debian.org/debian-security bullseye/updates InRelease
> Err:2 http://security.debian.org/debian-security bullseye/updates Release
>404  Not Found [IP: 199.232.138.132 80]
> Hit:3 http://mirror.init7.net/debian bullseye InRelease
> Hit:4 http://mirror.init7.net/debian bullseye-updates InRelease
> Reading package lists... Done
> E: The repository 'http://security.debian.org/debian-security
> bullseye/updates Release' does not have a Release file.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.
> 
> 
> cat /etc/apt/sources.list
> #
> 
> # deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 xfce-CD
> Binary-1 20210619-16:12]/ bullseye main
> 
> #deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 xfce-CD
> Binary-1 20210619-16:12]/ bullseye main
> 
> deb http://mirror.init7.net/debian/ bullseye main contrib non-free
> deb-src http://mirror.init7.net/debian/ bullseye main contrib non-free
> 
> deb http://security.debian.org/debian-security bullseye/updates main
> contrib non-free
> deb-src http://security.debian.org/debian-security bullseye/updates main
> contrib non-free
> 
> # bullseye-updates, previously known as 'volatile'
> deb http://mirror.init7.net/debian/ bullseye-updates main contrib non-free
> deb-src http://mirror.init7.net/debian/ bullseye-updates main contrib
> non-free
> 
> # This system was installed using small removable media
> # (e.g. netinst, live or single CD). The matching "deb cdrom"
> # entries were disabled at the end of the installation process.
> # For information about how to configure apt package sources,
> # see the sources.list(5) manual.
> 
> kind regards
> Evelyn




signature.asc
Description: This is a digitally signed message part.

Re: what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[Brian]

On Sun 15 Aug 2021 at 12:06:18 -0400, The Wanderer wrote:

> On 2021-08-15 at 12:00, Evelyn Pereira Souza wrote:
> 
> > Hi
> > 
> > apt-get update
> > Ign:1 http://security.debian.org/debian-security bullseye/updates InRelease
> > Err:2 http://security.debian.org/debian-security bullseye/updates Release
> >404  Not Found [IP: 199.232.138.132 80]
> 
> > deb http://security.debian.org/debian-security bullseye/updates main 
> > contrib non-free
> 
> This 'suite/updates' syntax is apparently no longer correct for
> security.debian.org.
> 
> I'm not familiar with the use of this 'debian-security' affix on the
> repository URL, but for comparison, my own sources.list now has:
> 
> deb http://security.debian.org/ testing-security main contrib non-free
> 
> and I'm not getting this 404 anymore.
> 
> You might try something analogous (probably with 'bullseye-security') in
> place of 'bullseye/updates', and see whether it helps.

I have

 deb http://security.debian.org/debian-security bullseye-security main

-- 
Brian.

Re: what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[The Wanderer]

On 2021-08-15 at 12:00, Evelyn Pereira Souza wrote:

> Hi
> 
> apt-get update
> Ign:1 http://security.debian.org/debian-security bullseye/updates InRelease
> Err:2 http://security.debian.org/debian-security bullseye/updates Release
>404  Not Found [IP: 199.232.138.132 80]

> deb http://security.debian.org/debian-security bullseye/updates main contrib 
> non-free

This 'suite/updates' syntax is apparently no longer correct for
security.debian.org.

I'm not familiar with the use of this 'debian-security' affix on the
repository URL, but for comparison, my own sources.list now has:

deb http://security.debian.org/ testing-security main contrib non-free

and I'm not getting this 404 anymore.

You might try something analogous (probably with 'bullseye-security') in
place of 'bullseye/updates', and see whether it helps.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

what's wrong with my "/etc/apt/sources.list"? Updating from such a repository can't be done securely, and is therefore disabled by default

[Evelyn Pereira Souza]

Hi

apt-get update
Ign:1 http://security.debian.org/debian-security bullseye/updates InRelease
Err:2 http://security.debian.org/debian-security bullseye/updates Release
  404  Not Found [IP: 199.232.138.132 80]
Hit:3 http://mirror.init7.net/debian bullseye InRelease
Hit:4 http://mirror.init7.net/debian bullseye-updates InRelease
Reading package lists... Done
E: The repository 'http://security.debian.org/debian-security 
bullseye/updates Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is 
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user 
configuration details.



cat /etc/apt/sources.list
#

# deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 xfce-CD 
Binary-1 20210619-16:12]/ bullseye main


#deb cdrom:[Debian GNU/Linux 10.10.0 _Buster_ - Official amd64 xfce-CD 
Binary-1 20210619-16:12]/ bullseye main


deb http://mirror.init7.net/debian/ bullseye main contrib non-free
deb-src http://mirror.init7.net/debian/ bullseye main contrib non-free

deb http://security.debian.org/debian-security bullseye/updates main 
contrib non-free
deb-src http://security.debian.org/debian-security bullseye/updates main 
contrib non-free


# bullseye-updates, previously known as 'volatile'
deb http://mirror.init7.net/debian/ bullseye-updates main contrib non-free
deb-src http://mirror.init7.net/debian/ bullseye-updates main contrib 
non-free


# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

kind regards
Evelyn


OpenPGP_0x61776FA8E38403FB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: APT Sources.list Line Format for Security Updates

[Gregory McPherran]

Hi Andy, I've already been using 11 (Bullseye) for months. My question was 
specific and related to documentation discrepancy regarding sources.list . I 
have been provided satisfactory answers regarding that and am all set.

Greg McPherran


From: Andrew M.A. Cater 
Sent: Tuesday, July 13, 2021 6:22 AM
To: debian-user@lists.debian.org 
Subject: Re: APT Sources.list Line Format for Security Updates

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> Hi,
>
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FDebianBullseye%3Fhighlight%3D%2528CategoryRelease%2529%23New_Features&data=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625810937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SFTH3eR%2F%2BLwbAt4hr2%2BElfPrgfyd%2BMSi%2FGBjwjnncYI%3D&reserved=0>
> deb  
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2Fdebian-security&data=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=psaVL5ThDddY38whq6Bq%2Bah51Qf2eMKp%2BNdvz0alAJE%3D&reserved=0
>bullseye-securitymain
>
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmanpages.debian.org%2Funstable%2Fapt%2Fsources.list.5.en.html%23EXAMPLES&data=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lN5yHj9UiBr1T%2BPeJJLUXrlSD6OMeWjuLrWHhJnbw1U%3D&reserved=0>
> deb  
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2F&data=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wNI3mPgA%2F88EARmq6lLoRpG4qaza92gpygscbtMu6MM%3D&reserved=0
>  bullseye-securitymain
>
> Is one of
> "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2Fdebian-security&data=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=psaVL5ThDddY38whq6Bq%2Bah51Qf2eMKp%2BNdvz0alAJE%3D&reserved=0";
> or   
> "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2F&data=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wNI3mPgA%2F88EARmq6lLoRpG4qaza92gpygscbtMu6MM%3D&reserved=0";
>the correct format ?
>
> Or is the "debian-security" portion optional ?
>
> Thank you,
> Greg McPherran
>

If you're still running Jessie: _please_ take the machine off the Internet
/ take it out of service to be upgraded. You're more than a year beyond all
major securiy support - unless you want to pay for ELTS.

Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
Debian 11 should be here inside a month - if you can get to 10, you'll
have at least a further year of security support for 10.

If you want detailed instructions as to how to go about this, this list
will be more than happy to oblige, I'm sure.

[Second time in 24 hours: on IRC last night I was chatting with someone in
a similar position].

Upgrading between major releases of Debian is almost always feasible and
relatively problem free. In that, we score as against some other Linux
distributions where the only option is to wipe and reinstall.

"I can't upgrade at this time" is fine for maybe a year or even two at
the outside: saying this one time after formal security support has gone
is substantially less good for you and any other users of the machine.

Andy - who is overly tweaked about keeping systems up to date and patched.

All best, as ever,

Andy Cater

Re: APT Sources.list Line Format for Security Updates

[Andrew M.A. Cater]

On Tue, Jul 13, 2021 at 08:52:18AM -0400, Michael Stone wrote:
> On Tue, Jul 13, 2021 at 10:22:17AM +, Andrew M.A. Cater wrote:
> > Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
> > Debian 11 should be here inside a month - if you can get to 10, you'll
> > have at least a further year of security support for 10.
> 
> Worth noting that skipping releases when upgrading isn't supported, so
> there's no advantage to waiting for the next one--you'll still have to
> upgrade in order.

So: havng done this - 7 - 8 - 9 on an old machine at work was not too
difficult if you take it steadily.

You face at least two changes to get it oldoldstable soon :(

Andy C

> 

Re: APT Sources.list Line Format for Security Updates

[Michael Stone]

On Tue, Jul 13, 2021 at 10:22:17AM +, Andrew M.A. Cater wrote:

Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
Debian 11 should be here inside a month - if you can get to 10, you'll
have at least a further year of security support for 10.


Worth noting that skipping releases when upgrading isn't supported, so 
there's no advantage to waiting for the next one--you'll still have to 
upgrade in order.

Re: APT Sources.list Line Format for Security Updates

[Andrew M.A. Cater]

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> Hi,
> 
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
> deb  http://security.debian.org/debian-security   bullseye-security   
>  main
> 
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
> deb  http://security.debian.org 
> bullseye-securitymain
> 
> Is one of"http://security.debian.org/debian-security";or   
> "http://security.debian.org";   the correct format ?
> 
> Or is the "debian-security" portion optional ?
> 
> Thank you,
> Greg McPherran
> 

If you're still running Jessie: _please_ take the machine off the Internet 
/ take it out of service to be upgraded. You're more than a year beyond all
major securiy support - unless you want to pay for ELTS.

Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
Debian 11 should be here inside a month - if you can get to 10, you'll 
have at least a further year of security support for 10.

If you want detailed instructions as to how to go about this, this list
will be more than happy to oblige, I'm sure.

[Second time in 24 hours: on IRC last night I was chatting with someone in
a similar position].

Upgrading between major releases of Debian is almost always feasible and
relatively problem free. In that, we score as against some other Linux
distributions where the only option is to wipe and reinstall.

"I can't upgrade at this time" is fine for maybe a year or even two at
the outside: saying this one time after formal security support has gone
is substantially less good for you and any other users of the machine.

Andy - who is overly tweaked about keeping systems up to date and patched.

All best, as ever,

Andy Cater

Re: APT Sources.list Line Format for Security Updates

[Andrei POPESCU]

On Lu, 12 iul 21, 18:55:30, Gregory McPherran wrote:
> Hi,
> 
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
> deb  http://security.debian.org/debian-security   bullseye-security   
>  main
> 
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
> deb  http://security.debian.org 
> bullseye-securitymain
> 
> Is one of"http://security.debian.org/debian-security";or   
> "http://security.debian.org";   the correct format ?

APT repositories are real URLs that you can open in a browser, the first 
part should work as is.

If you want to open the full path in a browser remember to add '/dists/' 
between the URL and the distribution (in this case 'bullseye-security') 
and an additional '/' for the component (in this case 'main'), like 
this:

http://security.debian.org/debian-security/dists/bullseye-security/main


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: APT Sources.list Line Format for Security Updates

[Brian Thompson]

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
>Is one of"http://security.debian.org/debian-security";or   
>"http://security.debian.org";   the correct format ?
>
>Or is the "debian-security" portion optional ?

I don't think `debian-security` in the URL suffix is optional.  Use the
former instead of the latter and set the suite to `bullseye-security` as
well.
-- 
Best regards,

Brian T

Coronavirus is a scam.
9/11 was an inside job.


signature.asc
Description: PGP signature

APT Sources.list Line Format for Security Updates - Documentation Discrepancy

[Gregory McPherran]

Hi,

This shows the new security line form as:
DebianBullseye - Debian 
Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
deb  http://security.debian.org/debian-security   bullseye-security 
   main

This shows the new security line form as:
sources.list(5) — apt — Debian unstable — Debian 
Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
deb  http://security.debian.org 
bullseye-securitymain

Is one of"http://security.debian.org/debian-security";or   
"http://security.debian.org<http://security.debian.org/>"   the correct format ?

Or is the "debian-security" portion optional ?

Thank you,
Greg McPherran



From: Gregory McPherran 
Sent: Monday, July 12, 2021 2:55 PM
To: debian-user@lists.debian.org 
Subject: APT Sources.list Line Format for Security Updates

Hi,

This shows the new security line form as:
DebianBullseye - Debian 
Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
deb  http://security.debian.org/debian-security   bullseye-security 
   main

This shows the new security line form as:
sources.list(5) — apt — Debian unstable — Debian 
Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
deb  http://security.debian.org 
bullseye-securitymain

Is one of"http://security.debian.org/debian-security";or   
"http://security.debian.org";   the correct format ?

Or is the "debian-security" portion optional ?

Thank you,
Greg McPherran

Re: APT Sources.list Line Format for Security Updates

[Michael Stone]

On Mon, Jul 12, 2021 at 04:32:52PM -0400, Greg Wooledge wrote:

Try both and see which one works.  If the wiki is wrong, edit the wiki so
that it's correct.  (Then hope some jerk doesn't revert your changes.)


There's only one person acting like a jerk here.

Re: APT Sources.list Line Format for Security Updates

[Dan Ritter]

Greg Wooledge wrote: 
> On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> > This shows the new security line form as:
> > DebianBullseye - Debian 
> > Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
> > deb  http://security.debian.org/debian-security   bullseye-security 
> >main
> > 
> > This shows the new security line form as:
> > sources.list(5) — apt — Debian unstable — Debian 
> > Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
> > deb  http://security.debian.org 
> > bullseye-securitymain
> > 
> > Is one of"http://security.debian.org/debian-security";or   
> > "http://security.debian.org";   the correct format ?
> > 
> > Or is the "debian-security" portion optional ?
> 
> Try both and see which one works.  If the wiki is wrong, edit the wiki so
> that it's correct.  (Then hope some jerk doesn't revert your changes.)
> If the man page is wrong, file a bug report and pray that the man page
> will be fixed in a post-11.0 point release.

On my test bullseye desktop:

deb http://security.debian.org/debian-security bullseye-security main

works without complaint.

-dsr-

Re: APT Sources.list Line Format for Security Updates

[Greg Wooledge]

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
> deb  http://security.debian.org/debian-security   bullseye-security   
>  main
> 
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
> deb  http://security.debian.org 
> bullseye-securitymain
> 
> Is one of"http://security.debian.org/debian-security";or   
> "http://security.debian.org";   the correct format ?
> 
> Or is the "debian-security" portion optional ?

Try both and see which one works.  If the wiki is wrong, edit the wiki so
that it's correct.  (Then hope some jerk doesn't revert your changes.)
If the man page is wrong, file a bug report and pray that the man page
will be fixed in a post-11.0 point release.

APT Sources.list Line Format for Security Updates

[Gregory McPherran]

Hi,

This shows the new security line form as:
DebianBullseye - Debian 
Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
deb  http://security.debian.org/debian-security   bullseye-security 
   main

This shows the new security line form as:
sources.list(5) — apt — Debian unstable — Debian 
Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
deb  http://security.debian.org 
bullseye-securitymain

Is one of"http://security.debian.org/debian-security";or   
"http://security.debian.org";   the correct format ?

Or is the "debian-security" portion optional ?

Thank you,
Greg McPherran

Re: Editing /etc/apt/sources.list breaks update

[Juha Manninen]

On Thu, Sep 21, 2017 at 12:29 AM, Fungi4All  wrote:
> LXDE is much more reliable than lxqt.

LXQT was buggy and broken still a year or so ago. Now it works nicely
and looks good.
It will finally replace LXDE.
It provides a light environment especially if you can use other QT applications.
I tried it in both SparkyLinux and Debian testing.

Even KDE Plasma 5 is amazingly light when used together with QT
applications which is demonstrated nicely by KaOS. Wow!
Some people still remember KDE as bloated and slow. It was true with KDE4.


> You can have a bootable system with openbox starting at 100MB.  But
> the momment you open up a fancy browser with 5-10 tabs you better
> have a good swap space or it will crash.  You can run Dillo or Midori
> as a browser one tab at a time, but it is best to get a little more ram.

Not really. Half a Gig of RAM is sufficient for heavy browsing with
Firefox. Swap space is good to have of course but it doesn't swap too
much, meaning the system does not slow down noticeably.
The computer I talked about belongs to a friend and has now Mint 13 +
XFCE which fittet into a CD back then.
It has got no updates for years and thus should be replaced.
Programs in a 32-bit system consume less memory than in a 64-bit
system. It is understandable because all pointers and some integers in
memory are half the size.

I also have a Pentium II, 266 MHz, 380MB memory.
It is also very usable although such computers are now considered obsolete!
It was good for professional CAD work a long time ago. Why would it be
obsolete now?
It now has an old PCLinuxOS which also should be replaced.

Juha

Re: Editing /etc/apt/sources.list breaks update

[Juha Manninen]

On Thu, Sep 21, 2017 at 12:08 AM, Fungi4All  wrote:
> I don't think it says such a thing anywhere, buster can not change
> to testing as there is nothing to change for the next 2 years.
>
> I say you cut that ftp.fi and make it into deb.debian and then
> $ sudo apt update
> $ sudo apt-get dist-upgrade
> $ sudo apt autoremove
> and your testing or buster will work fine.

I tried different URLs but it did not help. Same errors about GPG.

Sources in SparkyLinux :
---
deb http://ftp.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free
deb http://www.deb-multimedia.org testing main non-free

They are Debian servers except maybe the last one.
I still don't understand why they can write "testing" and it works but
I cannot do it in Debian installation.
Anyway, no big deal. I will continue with the default values.

Juha

Re: Editing /etc/apt/sources.list breaks update

[Juha Manninen]

On Wed, Sep 20, 2017 at 12:51 AM, Fungi4All  wrote:
> Isn't Debian 9.1 Stretch?

Ah damn, the "9.1" was a typo from me. I experimented with both
Stretch and the testing installations under VirtualBox.
My post was about "testing" which is now "buster", installed from:
 debian-testing-i386-netinst.iso


> Isn't Buster the same as testing for the next 2 years, give and take
> a few months?  So there will be no change.  Have I missed
> something?

I wanted to experiment about how Debian testing works as a rolling
distro. I have read some people do it successfully. I have good
experiences of other rolling distros myself, namely Manjaro and
SparkyLinux.
SparkyLinux is based on Debian testing but it has no proper installer
with memory < 1GB. :(

Now having a rolling Debian is not the main issue, it is more about
problem solving. Why things don't work as advertised?


> It now looks like this :
> deb http://ftp.fi.debian.org/debian/ testing main
> deb-src http://ftp.fi.debian.org/debian/ testing main
> # deb http://security.debian.org/debian-security testing/updates main
> deb http://deb.debian.org/debian/ testing contrib main
> # deb-src http://security.debian.org/debian-security testing/updates main
>
> Who changed stretch to buster?  Why change buster to testing?
> I keep reading the responses wondering why the rest are responding
> the way they do.  Like something obvious was overseen!

There was "buster" and I changed it to "testing" as advertised here:
 https://wiki.debian.org/DebianTesting
It should be possible by all logic. Why isn't it? Can you reproduce
the problem? I am curious what exactly happens.


> PS  I still have a VHS of Juha Kankunen and his Lancia 037!
> It is the first thing that flashes in my head when I hear Juha.

:)

Juha M.

Re: Editing /etc/apt/sources.list breaks update

[Fungi4All]

> From: juha.mannine...@gmail.com
> To: debian-user@lists.debian.org
>
> Hello Debian people! My first post here.
>
> I have installed Debian 9.1.0 buster for i386 using the small netinst
> image. Works well. I tested different desktops, too.

Isn't Debian 9.1 Stretch?

> I wanted to use the testing branch also after buster goes stable.

Isn't this Spring/Summer 2019?

> According to this page:
> https://wiki.debian.org/DebianTesting
> it is possible by editing /etc/apt/sources.list.
> I followed the instructions and changed "buster" to "testing" and
> commented out security update lines.

Isn't Buster the same as testing for the next 2 years, give and take
a few months?  So there will be no change.  Have I missed
something?

> It now looks like this :
> deb http://ftp.fi.debian.org/debian/ testing main
> deb-src http://ftp.fi.debian.org/debian/ testing main
> # deb http://security.debian.org/debian-security testing/updates main
> deb http://deb.debian.org/debian/ testing contrib main
> # deb-src http://security.debian.org/debian-security testing/updates main

Who changed stretch to buster?  Why change buster to testing?
I keep reading the responses wondering why the rest are responding
the way they do.  Like something obvious was overseen!

PS  I still have a VHS of Juha Kankunen and his Lancia 037!
It is the first thing that flashes in my head when I hear Juha.

Re: Editing /etc/apt/sources.list breaks update

[David Margerison]

On 16 September 2017 at 23:25, Erik Christiansen
 wrote:
> On 16.09.17 15:44, Juha Manninen wrote:

>> BTW, the reply address of this mailing list is set wrong. In some
>> other lists I can click Reply and it goes to the list. Here it would
>> go to the person who sent the last message. I have to edit the
>> recipient field.

Juha, that is because those other lists set the "Reply-To" header to
themselves, in the belief that it reduces confusion for users who
are using inadequate email clients.

However that is a misuse of that header (because its purpose is for
the writer of the email to specify a different email address of their own
where they prefer to receive replies they want replies to go), so this
list does not do that.

More information is at:
  http://www.unicom.com/pw/reply-to-harmful.html
  http://marc.merlins.org/netrants/reply-to-still-harmful.html

> The deficiency lies in your MUA settings.

No, the deficiency lies in gmail.

On 17 September 2017 at 23:55, Erik Christiansen
 wrote:
> On 16.09.17 21:28, Juha Manninen wrote:

>> I use the browser interface for GMail. Ok, it is not very geeky but it
>> works for me.
>> I cannot see any GMail setting that would affect this issue.
>> If somebody has ideas, please tell me.

> Comparing the "List-..." headers provided on other lists may reveal what
> gmail is relying on for list detection, but google might do that too.

Gmail does not do any list detection.

Gmail offers only "Reply" or "Reply-to-all" capability, like those other
inadequate email clients I mentioned above.

Re: Editing /etc/apt/sources.list breaks update

[Erik Christiansen]

On 16.09.17 21:28, Juha Manninen wrote:
> On Sat, Sep 16, 2017 at 4:25 PM, Erik Christiansen
> > List-Id: 
> > List-Post: 
...

> I use the browser interface for GMail. Ok, it is not very geeky but it
> works for me.
> I cannot see any GMail setting that would affect this issue.
> If somebody has ideas, please tell me.

Comparing the "List-..." headers provided on other lists may reveal what
gmail is relying on for list detection, but google might do that too.
Once you've identified your need, a request to the list admin for an
additional header might be worth a try.

Erik

Re: Editing /etc/apt/sources.list breaks update

[Juha Manninen]

On Sat, Sep 16, 2017 at 4:25 PM, Erik Christiansen
 wrote:
> The deficiency lies in your MUA settings. Take a look at the headers on
> the list traffic you receive:
>
> List-Id: 
> List-Post: 
>
> Without knowing which MUA you use, it's difficult to do the work for
> you, but if it's mutt, then adding a "subscribe debian-user.lists.debian.org"
> line to .muttrc may do the trick. (Depending on what else is or isn't
> set.) There, though, it is better to initiate a "List Reply" rather than
> a "Reply" (to author), in this use case. That works for me without the
> need for a subscribe line. (So no problem here. ;-)

I use the browser interface for GMail. Ok, it is not very geeky but it
works for me.
I cannot see any GMail setting that would affect this issue.
If somebody has ideas, please tell me.
I post to other mailing lists, too, mainly related to FPC and Lazarus
Pascal stuff.
I don't remember setting anything for e-mail reply addresses.

Juha Manninen

Re: Editing /etc/apt/sources.list breaks update

[Sven Hartge]

Eero Volotinen  wrote:

> You need to import needed gpg key.

> Try something like this

> gpg --keyserver pgpkeys.mit.edu --recv-key  7638D0442B90D010

> gpg -a --export 7638D0442B90D010 | sudo apt-key add -

No!

You should *never* manually import any ReleaseKey. Those should always
only come from the keyring packages in Debian itself or your system may
end up trusting a key which has been removed from the official keyeing.

S°

-- 
Sigmentation fault. Core dumped.

Re: Editing /etc/apt/sources.list breaks update

[Erik Christiansen]

On 16.09.17 15:44, Juha Manninen wrote:
> BTW, the reply address of this mailing list is set wrong. In some
> other lists I can click Reply and it goes to the list. Here it would
> go to the person who sent the last message. I have to edit the
> recipient field.

The deficiency lies in your MUA settings. Take a look at the headers on
the list traffic you receive:

List-Id: 
List-Post: 

Without knowing which MUA you use, it's difficult to do the work for
you, but if it's mutt, then adding a "subscribe debian-user.lists.debian.org"
line to .muttrc may do the trick. (Depending on what else is or isn't
set.) There, though, it is better to initiate a "List Reply" rather than
a "Reply" (to author), in this use case. That works for me without the
need for a subscribe line. (So no problem here. ;-)

Erik

Re: Editing /etc/apt/sources.list breaks update

[Juha Manninen]

# export LC_MESSAGES=C
root@debian:/home/juha# gpg --keyserver pgpkeys.mit.edu --recv-key
7638D0442B90D010
key 7638D0442B90D010:
10 signatures not checked due to missing keys
gpg: key 7638D0442B90D010: "Debian Archive Automatic Signing Key
(8/jessie) " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
root@debian:/home/juha# gpg -a --export 7638D0442B90D010 | apt-key add -
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
gpg: keydb_search failed: Invalid argument
key 7638D0442B90D010:
10 signatures not checked due to missing keys
gpg: keydb_get_keyblock failed: Value not found

---

Anyway running such commands felt strange because it is not mentioned
in documentation and quite impossible to guess.
This all means the "DebianTesting" web page is wrong. The task is not
as easy as it claims. It should be fixed.

Anyway it is not a big problem for me. I can continue with the default
sources.list.
Debian still looks like the best choice for old computer + CD install.
I tried SparkyLinux which is advertised for old computers. They have a
minimalGUI image but its GUI installer requires 1GB memory! The CLI
"advanced installer" is not advanced at all and left me with a partly
broken system.
I just tried Fedora. Even their "light" LXQT spin hogs memory and
feels sticky.  :(
Arch, Manjaro and many others have dropped support for 32-bit. Ubuntu
is planning to do so ...

Puppy Linux and such are too minimal, designed for truly limited resources.
The computer I will update has plenty of resources: An AMD CPU of
almost 2 GHz and half a gigabyte of memory. That is 536870912 bytes,
for God's sake! It is not an obsolete machine.

BTW, the reply address of this mailing list is set wrong. In some
other lists I can click Reply and it goes to the list. Here it would
go to the person who sent the last message. I have to edit the
recipient field.

Regards,
Juha Manninen

Re: Editing /etc/apt/sources.list breaks update

[Teemu Likonen]

Juha Manninen [2017-09-16 11:57:32+03] wrote:

> # apt-get update
> Nouda:1 http://deb.debian.org/debian testing InRelease [135 kB]
> Vrhe:1 http://deb.debian.org/debian testing InRelease
>   Seuraavia allekirjoituksia ei voinut varmentaa koska julkista
> avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010

> Sorry, some errors are in Finnish due to my locale. I can try to
> change that if required.

Hint for the locale in an international mailing list:

# export LC_MESSAGES=C
# apt-get update

or for one command only

# LC_MESSAGES=C apt-get update

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


signature.asc
Description: PGP signature

Re: Editing /etc/apt/sources.list breaks update

[Eero Volotinen]

Hi,

You need to import needed gpg key.

Try something like this

gpg --keyserver pgpkeys.mit.edu --recv-key  7638D0442B90D010

gpg -a --export 7638D0442B90D010 | sudo apt-key add -


--
Eero

2017-09-16 11:57 GMT+03:00 Juha Manninen :

> Hello Debian people! My first post here.
>
> I have installed Debian 9.1.0 buster for i386 using the small netinst
> image. Works well. I tested different desktops, too.
>
> I wanted to use the testing branch also after buster goes stable.
> According to this page:
>   https://wiki.debian.org/DebianTesting
> it is possible by editing /etc/apt/sources.list.
> I followed the instructions and changed "buster" to "testing" and
> commented out security update lines.
> It now looks like this :
>  deb http://ftp.fi.debian.org/debian/ testing main
>  deb-src http://ftp.fi.debian.org/debian/ testing main
>  # deb http://security.debian.org/debian-security testing/updates main
>  deb http://deb.debian.org/debian/ testing contrib main
>  # deb-src http://security.debian.org/debian-security testing/updates main
>
> However running:
> ---
> # apt-get update
> Nouda:1 http://deb.debian.org/debian testing InRelease [135 kB]
> Vrhe:1 http://deb.debian.org/debian testing InRelease
>   Seuraavia allekirjoituksia ei voinut varmentaa koska julkista
> avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
> Nouda:2 http://ftp.fi.debian.org/debian testing InRelease [135 kB]
> Vrhe:2 http://ftp.fi.debian.org/debian testing InRelease
>   Seuraavia allekirjoituksia ei voinut varmentaa koska julkista
> avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
> Noudettiin 270 kt ajassa 10s (26,7 kt/s)
> Luetaan pakettiluetteloita... Valmis
> W: An error occurred during the signature verification. The repository
> is not updated and the previous index files will be used. GPG error:
> http://deb.debian.org/debian testing InRelease: Seuraavia
> allekirjoituksia ei voinut varmentaa koska julkista avainta ei ole
> saatavilla: NO_PUBKEY 7638D0442B90D010
> W: An error occurred during the signature verification. The repository
> is not updated and the previous index files will be used. GPG error:
> http://ftp.fi.debian.org/debian testing InRelease: Seuraavia
> allekirjoituksia ei voinut varmentaa koska julkista avainta ei ole
> saatavilla: NO_PUBKEY 7638D0442B90D010
> W: Tiedoston http://ftp.fi.debian.org/debian/dists/testing/InRelease
> nouto ei onnistunut  Seuraavia allekirjoituksia ei voinut varmentaa
> koska julkista avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
> W: Tiedoston http://deb.debian.org/debian/dists/testing/InRelease
> nouto ei onnistunut  Seuraavia allekirjoituksia ei voinut varmentaa
> koska julkista avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
> W: Some index files failed to download. They have been ignored, or old
> ones used instead.
> ---
>
> Sorry, some errors are in Finnish due to my locale. I can try to
> change that if required.
> I found some post about GPG errors but no solutions really.
> I have read some people successfully run Debian testing as a rolling
> distro and the "DebianTesting" web page also says it is possible.
> I am curious what is happening.
>
> BTW, the web page has conflicting info. After an orange exclamation
> mark it says:
>  "If you are tracking testing or the next-stable code name, you should
> always have a corresponding deb http://security.debian.org <"testing"
> or codename>/updates main line in your /etc/apt/sources.list ."
> ... although just earlier it told to remove any security lines.
> This has no effect on the errors though.
>
> Now I am testing with VirtualBox. Later my goal is to keep some old
> machines alive. They only can boot from a CD, no DVD nor USB.
> Distros that support installation for such machines are getting
> sparse. Most distros have dropped CD size images and also 32-bit CPUs.
>
>
> Regards,
> Juha Manninen
>
>

Editing /etc/apt/sources.list breaks update

[Juha Manninen]

Hello Debian people! My first post here.

I have installed Debian 9.1.0 buster for i386 using the small netinst
image. Works well. I tested different desktops, too.

I wanted to use the testing branch also after buster goes stable.
According to this page:
  https://wiki.debian.org/DebianTesting
it is possible by editing /etc/apt/sources.list.
I followed the instructions and changed "buster" to "testing" and
commented out security update lines.
It now looks like this :
 deb http://ftp.fi.debian.org/debian/ testing main
 deb-src http://ftp.fi.debian.org/debian/ testing main
 # deb http://security.debian.org/debian-security testing/updates main
 deb http://deb.debian.org/debian/ testing contrib main
 # deb-src http://security.debian.org/debian-security testing/updates main

However running:
---
# apt-get update
Nouda:1 http://deb.debian.org/debian testing InRelease [135 kB]
Vrhe:1 http://deb.debian.org/debian testing InRelease
  Seuraavia allekirjoituksia ei voinut varmentaa koska julkista
avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
Nouda:2 http://ftp.fi.debian.org/debian testing InRelease [135 kB]
Vrhe:2 http://ftp.fi.debian.org/debian testing InRelease
  Seuraavia allekirjoituksia ei voinut varmentaa koska julkista
avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
Noudettiin 270 kt ajassa 10s (26,7 kt/s)
Luetaan pakettiluetteloita... Valmis
W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error:
http://deb.debian.org/debian testing InRelease: Seuraavia
allekirjoituksia ei voinut varmentaa koska julkista avainta ei ole
saatavilla: NO_PUBKEY 7638D0442B90D010
W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error:
http://ftp.fi.debian.org/debian testing InRelease: Seuraavia
allekirjoituksia ei voinut varmentaa koska julkista avainta ei ole
saatavilla: NO_PUBKEY 7638D0442B90D010
W: Tiedoston http://ftp.fi.debian.org/debian/dists/testing/InRelease
nouto ei onnistunut  Seuraavia allekirjoituksia ei voinut varmentaa
koska julkista avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
W: Tiedoston http://deb.debian.org/debian/dists/testing/InRelease
nouto ei onnistunut  Seuraavia allekirjoituksia ei voinut varmentaa
koska julkista avainta ei ole saatavilla: NO_PUBKEY 7638D0442B90D010
W: Some index files failed to download. They have been ignored, or old
ones used instead.
---

Sorry, some errors are in Finnish due to my locale. I can try to
change that if required.
I found some post about GPG errors but no solutions really.
I have read some people successfully run Debian testing as a rolling
distro and the "DebianTesting" web page also says it is possible.
I am curious what is happening.

BTW, the web page has conflicting info. After an orange exclamation
mark it says:
 "If you are tracking testing or the next-stable code name, you should
always have a corresponding deb http://security.debian.org <"testing"
or codename>/updates main line in your /etc/apt/sources.list ."
... although just earlier it told to remove any security lines.
This has no effect on the errors though.

Now I am testing with VirtualBox. Later my goal is to keep some old
machines alive. They only can boot from a CD, no DVD nor USB.
Distros that support installation for such machines are getting
sparse. Most distros have dropped CD size images and also 32-bit CPUs.


Regards,
Juha Manninen

Re: how to get xvid codec even though non-free is there in my /etc/apt/sources.list

[Nicolas George]

Le tridi 23 prairial, an CCXXV, shirish शिरीष a écrit :
> Vlc gives me this -
> 
> [7fa1180009c8] vdpau_avcodec generic error: decoder profile not 
> supported: 7

This means that it is trying to use a hardware-accelerated decoder, and
the hardware does not support decoding that particular video.

VLC should fall back to using a software codec, and be able to decode
that video without additional codec.

As a quick test, you should try ffplay.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: how to get xvid codec even though non-free is there in my /etc/apt/sources.list

[shirish शिरीष]

at bottom :-

On 11/06/2017, shirish शिरीष  wrote:
> Dear Friends,
>
> Please CC me as I'm not subscribed to the list. I am trying to watch a
> video which unfortunately uses xvid codec. I do have libxvidcore4
> installed (using stretch) but it still complains about not having the
> right codec. Can anyone help ?
>
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
> EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8
>

Vlc gives me this -

[7fa1180009c8] vdpau_avcodec generic error: decoder profile not supported: 7
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
[7fa11800cc08] vdpau_avcodec generic error: decoder profile not supported: 7

Maybe the above helps.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

how to get xvid codec even though non-free is there in my /etc/apt/sources.list

[shirish शिरीष]

Dear Friends,

Please CC me as I'm not subscribed to the list. I am trying to watch a
video which unfortunately uses xvid codec. I do have libxvidcore4
installed (using stretch) but it still complains about not having the
right codec. Can anyone help ?

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Re: debian 6.0.4 apt sources.list

[Greg Wooledge]

On Wed, Nov 09, 2016 at 09:41:52AM +0100, basti wrote:
> Hello,
> debian 6 is End-of-Life since 31. Mai 2014 (29. Februar 2016 for LTS), I
> recommend am upgrade.
> If it is not possible try "deb http://archive.debian.org/debian/ squeeze
> contrib main non-free" in sources.list,
> see https://www.debian.org/distrib/archive for more Infos.

Also see https://wiki.debian.org/DebianSqueeze which suggests using
these two lines:

deb http://archive.debian.org/debian squeeze main
deb http://archive.debian.org/debian squeeze-lts main

There is also a note about adding an option in /etc/apt/apt.conf to work
around an expired key.

Re: debian 6.0.4 apt sources.list

[Lisi Reisz]

I think you may not be subscribed, so here is your earlier question in 
addition to this one.

Lisi

On Tuesday 08 November 2016 06:09:16 Shawn Li (李松) wrote:
> Hello，
>
> I have downloaded debian-6.0.4-i386-DVD-1.iso from debian.org,and I install
> it to my computer.when the install finish,I got a AMD64 version debian.but
> my computer’s CPU is 32bit and the DVD iso is i386,
>
> could yout please tell me why? I just want to install a 32bit debian6
> os.thank you.
>
> Shawn

Why are you installing Debian 6???  And you can't install a 64 bit system on a 
32 bit computer.  You can try, but you won't succeed.  What makes you think 
that you have done so?

Lisi


On Wednesday 09 November 2016 08:12:05 Shawn Li (李松) wrote:
> hello，
>
> I have installed debian 6.0.4,but I can not install gcc by apt-get,maybe
> the sources.list error, could you please give me the correct sources.list
> can be use,thank you

See my earlier question.  It is almost  certainly a sources list error.  
Debian 6 is very old and is now in the archives.  

Have you resolved the 64/32 bit confusion?

Lisi

debian 6.0.4 apt sources.list

[李松]

hello，

I have installed debian 6.0.4,but I can not install gcc by apt-get,maybe the 
sources.list error, could you please give me the correct sources.list can be 
use,thank you

Re: Need /etc/apt/sources.list

[Lisi]

On Sunday 08 May 2011 22:12:23 Dotan Cohen wrote:
> That does not mean that I intend to
> debate the subject for three days over tens of posts.

So why are you doing it??

Here's a revolutionary idea: you could let someone else have the last word and 
get on with your life.  No-one but you yourself is making you debate the 
subject.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105091507.46827.lisi.re...@gmail.com

Re: Need /etc/apt/sources.list

[Camaleón]

On Mon, 09 May 2011 00:12:23 +0300, Dotan Cohen wrote:

> On Sun, May 8, 2011 at 13:28, Camaleón  wrote:

>>> There is a point when I don't care about being right or wrong, I made
>>> my say and I'll not argue over trivial things with people who I'd
>>> really rather get along with.
>>
>> Fine, but doing so in a public (and mostly technical) mailing list
>> generates other people reply to your "considerations" about a web
>> service that has been there providing a useful service since years.
>>
>>
> I mentioned problems with the service, both here-and-now problems and
> potential issues about the future. That does not mean that I intend to
> debate the subject for three days over tens of posts.

As I see it, you did more than just noting the tinyurl service was having 
any kind problem at your side or stating your concerns about its usage 
privacy issues. Again, I think your response was a bit exaggerated.

>>> I'm not trying to force anyone, nor am I making blame. I am giving
>>> tangible arguments in favour of my position. If someone wishes to
>>> disregard my arguments, even if it is to my detriment and the
>>> detriment of the fine archives, so be it.
>>
>> You are charging against Tinyurl and blaming over it because of some
>> obscure privacy concerns you have... but you are writing on a public
>> mailing list, you use Gmail and you still worry about privacy? That
>> makes no sense.
>>
>>
> Feel free to ignore the privacy aspects if they don't concern you. 

I'm concerned about privacy but clicking on a tinyurl link is not what I 
take for that.

> How about the ability to mask a malicious link? 

Irrelevant, as _any link_ (shortened or not) can be easily bypassed and 
point to a malicious site. 

> How about adding redundant layers to an already tenuous HTTP
> connection? 

Today's Internet is plenty of add-on layers, most of them useless.

> How about the future viability of the links when the shortening service
> has a server failure, or goes out of business, is bought, or hacked, or 
> shut down by law?

Again, *any* web URI can fail because of the same things. Should we care 
about all of the possibilities that can make a link is not functioning 
anymore? We can go crazy...

>> I used the Gmail argument because is a service that you are using but
>> apparently you are also much worried about your privacy. That's an
>> oxymoron. Probably by using Gmail's e-mail service you are being more
>> watched than by following a tinyurl link.
>>
>>
> I use Gmail for public mailing lists. I have my private and business
> mail at my own domain dotancohen.com.

And the same argument can be taken by people who use tinyurl services: 
they use it on mailing lists but not for their personal or business e-
mail communication.

>> I believe there is nothing wrong in using them. Heck, this is the web!
>> Most of the "plain" URIs are not available anymore because people
>> closes their sites and they stop caring about making a redirect to the
>> new ones. Links dead, regardless of the usage of URL shortening
>> services or no.
>>
>>
> That's a red herring argument. Do you also not wear a seatbelt because
> we are all going to die anyway? Same argument.

No, it's not. I'm just using an "ad-hominem" argument: what you say that 
is bad for tinyurl is also bad for any other URI.

>>> So why use it?
>>
>> To make a bunch of text short. To give the reader some sort of
>> usability (there are e-mail clients that do not wrap well a long
>> formatted URL or they even broke the full link). To provide "clarity"
>> to the whole message.
>>
>>
> The shortening services do not provide clarity. 

Nor plain URLs do. I hope you've heard about "phishing" and what it 
involves.

> Here is a clear URL:
> http://dotancohen.com/eng/noah_ergonomic_keyboard_layout.html You know
> where it is going, and the topic under discussion. You might recognize
> the domain name if it is a common one and base your trust on that. I'll
> open links to http://debian.org, but I won't open links to
> http://debian.on.nimp.org and seeing the URL is critical in that
> decision.

No, I don't know if that URL is a trusted source or not. I don't know 
you, nor I don't know if your webserver has been cracked by someone or if 
it contains malware on it... in fact no one can know it "beforehand".
 
> Here is a non-clear URL:
> http://tinyurl.com/2ajjgt
> Where does that go? Yes, I know about the "preview feature". I still
> have to invoke tinyurl to invoke the "preview feature".

I don't care where it goes. But _I do care_ if someone on this list 
points to me to that URI, shortened or not. Someone that is replying to 
me in order to help me.
 
>> There is a saying that says: "When the wise man points at the moon, the
>> idiot looks at the finger". In brief, I think that Tinyurl is no the
>> main question here.
>>
>>
> I counter with the saying "When the sage lifts his book, the slave
> lowers his pen". Tinyurl gives no benefit and [causes problems || has
> the poten

Re: Need /etc/apt/sources.list

[Dotan Cohen]

On Sun, May 8, 2011 at 13:28, Camaleón  wrote:
> On Sun, 08 May 2011 09:42:49 +0300, Dotan Cohen wrote:
>
>> On Sat, May 7, 2011 at 12:41, Camaleón  wrote:
 I just tried tinyurl with wget and got the same IP address (and 200
 response) as you. I didn't check the links, though.
>>>
>>> Then? Are you still getting trouble to reach the tinyurl web site? If
>>> yes, there could be a filter/proxy in between of you and the website,
>>> that is, your ISP.
>>>
>>>
>> I didn't try the links.
>
> You said (sic) "The tinyurl server is giving a 500 error."
>

Right, at the beginning of the thread.


>> There is a point when I don't care about being
>> right or wrong, I made my say and I'll not argue over trivial things
>> with people who I'd really rather get along with.
>
> Fine, but doing so in a public (and mostly technical) mailing list
> generates other people reply to your "considerations" about a web service
> that has been there providing a useful service since years.
>

I mentioned problems with the service, both here-and-now problems and
potential issues about the future. That does not mean that I intend to
debate the subject for three days over tens of posts.


>> I'm not trying to force anyone, nor am I making blame. I am giving
>> tangible arguments in favour of my position. If someone wishes to
>> disregard my arguments, even if it is to my detriment and the detriment
>> of the fine archives, so be it.
>
> You are charging against Tinyurl and blaming over it because of some
> obscure privacy concerns you have... but you are writing on a public
> mailing list, you use Gmail and you still worry about privacy? That makes
> no sense.
>

Feel free to ignore the privacy aspects if they don't concern you. How
about the ability to mask a malicious link? How about adding redundant
layers to an already tenuous HTTP connection? How about the future
viability of the links when the shortening service has a server
failure, or goes out of business, is bought, or hacked, or shut down
by law?


> I used the Gmail argument because is a service that you are using but
> apparently you are also much worried about your privacy. That's an
> oxymoron. Probably by using Gmail's e-mail service you are being more
> watched than by following a tinyurl link.
>

I use Gmail for public mailing lists. I have my private and business
mail at my own domain dotancohen.com.


> I believe there is nothing wrong in using them. Heck, this is the web!
> Most of the "plain" URIs are not available anymore because people closes
> their sites and they stop caring about making a redirect to the new ones.
> Links dead, regardless of the usage of URL shortening services or no.
>

That's a red herring argument. Do you also not wear a seatbelt because
we are all going to die anyway? Same argument.


>> So why use it?
>
> To make a bunch of text short. To give the reader some sort of usability
> (there are e-mail clients that do not wrap well a long formatted URL or
> they even broke the full link). To provide "clarity" to the whole message.
>

The shortening services do not provide clarity. Here is a clear URL:
http://dotancohen.com/eng/noah_ergonomic_keyboard_layout.html
You know where it is going, and the topic under discussion. You might
recognize the domain name if it is a common one and base your trust on
that. I'll open links to http://debian.org, but I won't open links to
http://debian.on.nimp.org and seeing the URL is critical in that
decision.

Here is a non-clear URL:
http://tinyurl.com/2ajjgt
Where does that go? Yes, I know about the "preview feature". I still
have to invoke tinyurl to invoke the "preview feature".


> There is a saying that says: "When the wise man points at the moon, the
> idiot looks at the finger". In brief, I think that Tinyurl is no the main
> question here.
>

I counter with the saying "When the sage lifts his book, the slave
lowers his pen". Tinyurl gives no benefit and [causes problems || has
the potential to cause problems].


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktinpixyu9vbte6jdu0be_w-62nj...@mail.gmail.com

Re: URL shortening (was Re: Need /etc/apt/sources.list)

[Robert Holtzman]

On Sun, May 08, 2011 at 09:28:54AM +0300, Dotan Cohen wrote:
> 
> There were actually a few cases of these link-shortening services
> going under. Tr.im went under and was bought, Canonical and Google
> both bought and saved one (I don't remember the names) and for a while
> bit.ly was under threat for violating Sharia law.

In what respect?

-- 
Bob Holtzman
Key ID: 8D549279
"If you think you're getting free lunch,
 check the price of the beer"


signature.asc
Description: Digital signature

Re: Need /etc/apt/sources.list

[Camaleón]

On Sun, 08 May 2011 09:42:49 +0300, Dotan Cohen wrote:

> On Sat, May 7, 2011 at 12:41, Camaleón  wrote:
>>> I just tried tinyurl with wget and got the same IP address (and 200
>>> response) as you. I didn't check the links, though.
>>
>> Then? Are you still getting trouble to reach the tinyurl web site? If
>> yes, there could be a filter/proxy in between of you and the website,
>> that is, your ISP.
>>
>>
> I didn't try the links. 

You said (sic) "The tinyurl server is giving a 500 error."

> There is a point when I don't care about being
> right or wrong, I made my say and I'll not argue over trivial things
> with people who I'd really rather get along with.

Fine, but doing so in a public (and mostly technical) mailing list 
generates other people reply to your "considerations" about a web service 
that has been there providing a useful service since years.

>>> No, this is not a matter of preference.
>>
>> Sure it is. Nobody can force a user to use one or other method to post
>> into this list. You can follow the link or not, that's up to you, but
>> blaming someone -that is trying to help you- for using tinyurl (or any
>> other of those URL shortening services) is like an overreaction.
>>
>>
> I'm not trying to force anyone, nor am I making blame. I am giving
> tangible arguments in favour of my position. If someone wishes to
> disregard my arguments, even if it is to my detriment and the detriment
> of the fine archives, so be it.

You are charging against Tinyurl and blaming over it because of some 
obscure privacy concerns you have... but you are writing on a public 
mailing list, you use Gmail and you still worry about privacy? That makes 
no sense.

>>> There is no reason to pipe the links through some third party service
>>> that is unreliable and may, either through malice stupidity or
>>> hacking, compromise either the user's ability to connect to the site
>>> or perform undesirable actions (tracking, advertising, drive-by
>>> malware). Could TinyURL never be hacked? Sold? Forget to pay their
>>> hosting bill? Hardware failure? Network failure?
>>
>> Oh, come on! That argument is very flawed. Should we stop of using
>> Gmail e-mail service because of the same? >:-)
>>
>>
> Strawman. Gmail or any other email provider is providing an essential
> service: at most we could replace Gmail with a different email provider.
> That is not a link that can be taken out of the chain. Tinyurl, though,
> adds redundant links to the chain and they provide absolutely no
> benefit. So why use them? What is the benefit?

I used the Gmail argument because is a service that you are using but 
apparently you are also much worried about your privacy. That's an 
oxymoron. Probably by using Gmail's e-mail service you are being more 
watched than by following a tinyurl link.

>> Tinyurl, bit.ly and such have its use (mostly for twitter and sending
>> SMS messages that enforce you a policy of limited characters) but using
>> them in a mailing list is something is only up to the poster, not me,
>> nor you... there is no one point in Debian mailing list netiquette
>> stating the opposite.
>>
>>
> I don't read the Debian list on Twitter nor via SMS. Do you really
> believe that is such a viable use case that the benefits of a shorter
> URL outweigh the detriment?

I believe there is nothing wrong in using them. Heck, this is the web! 
Most of the "plain" URIs are not available anymore because people closes 
their sites and they stop caring about making a redirect to the new ones. 
Links dead, regardless of the usage of URL shortening services or no.

>>> What advantage exists at all to use tinyURL?
>>
>> It does not have to exist any.
>>
>>
> So why use it?

To make a bunch of text short. To give the reader some sort of usability 
(there are e-mail clients that do not wrap well a long formatted URL or 
they even broke the full link). To provide "clarity" to the whole message.

There is a saying that says: "When the wise man points at the moon, the 
idiot looks at the finger". In brief, I think that Tinyurl is no the main 
question here.

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2011.05.08.10.28...@gmail.com

Re: Need /etc/apt/sources.list

[Dotan Cohen]

On Sat, May 7, 2011 at 12:41, Camaleón  wrote:
>> I just tried tinyurl with wget and got the same IP address (and 200
>> response) as you. I didn't check the links, though.
>
> Then? Are you still getting trouble to reach the tinyurl web site? If
> yes, there could be a filter/proxy in between of you and the website,
> that is, your ISP.
>

I didn't try the links. There is a point when I don't care about being
right or wrong, I made my say and I'll not argue over trivial things
with people who I'd really rather get along with.


>>> That's a different issue. There is nothing that needs to be teached
>>> here because we are talking about "preferences". You don't like tinyurl
>>> and that's okay, no one can blame you for that, but in the same way you
>>> can't also blame others for use it... even less when that person was
>>> willing to help you.
>>>
>>>
>> No, this is not a matter of preference.
>
> Sure it is. Nobody can force a user to use one or other method to post
> into this list. You can follow the link or not, that's up to you, but
> blaming someone -that is trying to help you- for using tinyurl (or any
> other of those URL shortening services) is like an overreaction.
>

I'm not trying to force anyone, nor am I making blame. I am giving
tangible arguments in favour of my position. If someone wishes to
disregard my arguments, even if it is to my detriment and the
detriment of the fine archives, so be it.


>> There is no reason to pipe the links through some third party service
>> that is unreliable and may, either through malice stupidity or hacking,
>> compromise either the user's ability to connect to the site or perform
>> undesirable actions (tracking, advertising, drive-by malware). Could
>> TinyURL never be hacked? Sold? Forget to pay their hosting bill?
>> Hardware failure? Network failure?
>
> Oh, come on! That argument is very flawed. Should we stop of using Gmail
> e-mail service because of the same? >:-)
>

Strawman. Gmail or any other email provider is providing an essential
service: at most we could replace Gmail with a different email
provider. That is not a link that can be taken out of the chain.
Tinyurl, though, adds redundant links to the chain and they provide
absolutely no benefit. So why use them? What is the benefit?


> Tinyurl, bit.ly and such have its use (mostly for twitter and sending SMS
> messages that enforce you a policy of limited characters) but using them
> in a mailing list is something is only up to the poster, not me, nor
> you... there is no one point in Debian mailing list netiquette stating
> the opposite.
>

I don't read the Debian list on Twitter nor via SMS. Do you really
believe that is such a viable use case that the benefits of a shorter
URL outweigh the detriment?

>> What advantage exists at all to use tinyURL?
>
> It does not have to exist any.
>

So why use it?



-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimswil7z51g+s01daoideft4kg...@mail.gmail.com

Re: Need /etc/apt/sources.list

[Dotan Cohen]

On Sat, May 7, 2011 at 07:50, Freeman  wrote:
> Craigevil is very cool but his sources.list has open lines so I cleaned it
> up, I hope. It's late here. Check it. Especailly for something that wrapped.
>

That's great, thanks! I will go cherry-pick through there.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTiny0b2v_bZd1WijV6Y=n865tmy...@mail.gmail.com

Re: Need /etc/apt/sources.list

[Dotan Cohen]

On Fri, May 6, 2011 at 23:34, Heddle Weaver  wrote:
>> I appreciate your willingness to help, don't get me wrong. But just as
>> I am here to learn, I thought that you might also be interested in
>> learning the error of using url-shortening services.
>
> Oh, I remember you now.
>

Have we a history?

>> I apologise if I
>> stepped on toes or tried to teach the old dog new tricks.
>
> I'm always keen to learn.
> Where's the trick?
>

Don't use URL-shortening services.


>> But in any
>> case, even if I am fantasising about tracking or advertising, the
>> links are most certainly broken.
>
> I click on both of them and they lead me straight to the target, every time.
> Broken browser?
>

Possibly a broken browser, poisoned hosts file or DNS, a selective
firewall at work, or 100 other problems on my end (though none of
those would give HTTP error 500). But that only reinforces my
position: HTTP is already a tenuous protocol, why add more fragile
links to the chain?

> In any case, this situation has already absorbed too much of my time.

Agreed.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktik4j7l-+mkugwkwitpgp-xdxfo...@mail.gmail.com

Re: URL shortening (was Re: Need /etc/apt/sources.list)

[Dotan Cohen]

On Sat, May 7, 2011 at 01:33, Arno Schuring  wrote:
> However, this mailing list is archived. That means that links given on
> this mailing list are not simply fire-and-forget, they should be able
> to be resolved years from now. And while we cannot guarantee that any
> link remains valid, it is foolish to assume URL shorteners outlive the
> target website.
>
> In other words, please do not use (unnecessary) URL mangling. It
> needlessly makes your message useless for posterity.
>
>

There were actually a few cases of these link-shortening services
going under. Tr.im went under and was bought, Canonical and Google
both bought and saved one (I don't remember the names) and for a while
bit.ly was under threat for violating Sharia law.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimlf1tt_n_0w5s5fpcp6t_k0a_...@mail.gmail.com

Re: Need /etc/apt/sources.list

[Camaleón]

On Fri, 06 May 2011 23:07:15 +0300, Dotan Cohen wrote:

> I just tried tinyurl with wget and got the same IP address (and 200
> response) as you. I didn't check the links, though.

Then? Are you still getting trouble to reach the tinyurl web site? If 
yes, there could be a filter/proxy in between of you and the website, 
that is, your ISP.

>> That's a different issue. There is nothing that needs to be teached
>> here because we are talking about "preferences". You don't like tinyurl
>> and that's okay, no one can blame you for that, but in the same way you
>> can't also blame others for use it... even less when that person was
>> willing to help you.
>>
>>
> No, this is not a matter of preference. 

Sure it is. Nobody can force a user to use one or other method to post 
into this list. You can follow the link or not, that's up to you, but 
blaming someone -that is trying to help you- for using tinyurl (or any 
other of those URL shortening services) is like an overreaction.

> There is no reason to pipe the links through some third party service
> that is unreliable and may, either through malice stupidity or hacking,
> compromise either the user's ability to connect to the site or perform
> undesirable actions (tracking, advertising, drive-by malware). Could
> TinyURL never be hacked? Sold? Forget to pay their hosting bill?
> Hardware failure? Network failure?

Oh, come on! That argument is very flawed. Should we stop of using Gmail 
e-mail service because of the same? >:-)

Tinyurl, bit.ly and such have its use (mostly for twitter and sending SMS 
messages that enforce you a policy of limited characters) but using them 
in a mailing list is something is only up to the poster, not me, nor 
you... there is no one point in Debian mailing list netiquette stating 
the opposite. 
 
> What advantage exists at all to use tinyURL?

It does not have to exist any.

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2011.05.07.09.41...@gmail.com