On Sat, 21 Aug 2021, Vincent Lefevre wrote:
On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
The most naive attempt to mess with the update channel (intercepting the
http connection and replacing a package with a malicious one) will fail
immediately with both http or https. The primary differ
On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
> The most naive attempt to mess with the update channel (intercepting the
> http connection and replacing a package with a malicious one) will fail
> immediately with both http or https. The primary difference in that case
> with https is that the
On Fri, Aug 20, 2021 at 10:15 PM Timothy M Butterworth wrote:
> I give the installer a 5 star rating although I would like to see some
> improvements made to the disk configuration utility. Currently the
> disk configuration utility is non-intuitive and appears to be designed
> for keyboard only n
Ansgar writes:
> On Fri, 2021-08-20 at 23:37 +0200, Simon Richter wrote:
>> I was thinking of VPS hosting for the most part, where users will run
>> apt or auto-apt inside their virtual server.
> Hosting providers or ISPs messing with their customers' traffic with
> Debian mirrors seems like som
I have been using Debian 11 since Alpha 1 release. I installed with
non-free live DVD using the calamaris installer. I have it installed
on three systems one Intel Celeron, one Intel i5 and one AMD Ryzen 7.
I give the installer a 5 star rating although I would like to see some
improvements made to
Package: debian-policy
Version: 4.6.0.0
Tags: patch
X-debbugs-cc: Aurelien Jarno , debian-devel@lists.debian.org
On Wed 18 Aug 2021 at 02:10PM -07, Russ Allbery wrote:
> Sean Whitton writes:
>> On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote:
>
>>> This path is used by the multilib 64-bi
On Fri, 2021-08-20 at 23:37 +0200, Simon Richter wrote:
> I was thinking of VPS hosting for the most part, where users will run
> apt or auto-apt inside their virtual server.
Hosting providers or ISPs messing with their customers' traffic with
Debian mirrors seems like something we should not supp
Hi,
On 8/20/21 9:04 PM, Russ Allbery wrote:
One of the things that confuses me about this user story is why are your
containers doing non-trivial amounts of apt traffic at runtime? Generally
the whole point of a container is that you only do this during container
build time. I'm not sure I un
On Fri, 2021-08-20 at 12:11 -0700, Russ Allbery wrote:
> The way I would put it is that the security benefit of using TLS for apt
> updates is primarily that it makes certain classes of attempts to mess
> with the update channel more noisy and more likely to produce immediate
> errors.
APT is not
All,
Sorry I am a little late to this party so I have a new-be question,
what is the point of merged-usr? It seems like a lot of work for a
little reward, as the packages already work. Is there a legitimate
benefit for changing all these file paths that I am missing?
Thanks
Tim
Hi,
On 8/20/21 3:56 PM, Sam Hartman wrote:
Simon's position seemed to be that we need a dpkg update in order to
move forward and that we cannot depend on that mid-release.
Yes, except if we give up "apt dist-upgrade" as the interface for the
upgrade to the next stable release.
I can see
Quoting Jeremy Stanley (2021-08-20 18:34:22)
> > If so, I think the next step would be to open a bug with a summary of this
> > discussion. I'm happy to do that, but I'm not sure what package owns this
> > configuration.
> It's not owned directly by a particular package, I think D-I and various
>
On Fri, 2021-08-20 at 19:15 +0100, Simon McVittie wrote:
> On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> > I can confirm that if you build in split-usr mode then the generators
> > are looked for only in /lib:
> >
> > https://github.com/systemd/systemd/blob/v247/meson.build#L156
>
On 2021-08-20 12:04:02 -0700 (-0700), Russ Allbery wrote:
> Simon Richter writes:
>
> > I support that idea in principle, but one of our user stories is
> > "I have a datacenter with a few thousand containers in it, so I
> > want to redirect accesses to the local mirror to reduce external
> > net
Paul Gevers writes:
> I was told and I relayed early in this thread [1] that https gives you
> some (delayed) protection against man-in-the-middle attacks serving you
> old data.
Yes, it gives you some protection. Jeremy is more cynical about the
utility of that protection than I am, although i
Simon Richter writes:
> I support that idea in principle, but one of our user stories is "I have
> a datacenter with a few thousand containers in it, so I want to redirect
> accesses to the local mirror to reduce external network traffic."
Just checking that I understand. You have several thous
> We already have testing-proposed-updates with a different set of rules. See
> https://wiki.debian.org/TestingProposedUpdates
Ah, well ofcourse I knew about this. I ended up mis-taking it with the
companion suite proposed.
Please excuse me for being sloppy there :D
--
Sent from my Android de
On 2021-08-20 20:52:43 +0200 (+0200), Paul Gevers wrote:
[...]
> I was told and I relayed early in this thread [1] that https gives you
> some (delayed) protection against man-in-the-middle attacks serving you
> old data. Does everybody agree that this is either not prevented or not
> giving you mo
Hi,
On 20-08-2021 17:48, Russ Allbery wrote:
> It sounds like we have a general consensus in this thread that, while
> changing our default to HTTPS probably won't make anything more secure in
> practice, we should still do it?
I was told and I relayed early in this thread [1] that https gives yo
On 8/20/21 2:37 PM, Simon Richter wrote:
This is a use case where HTTPS does hurt, and where I can't think of
any good mitigation strategies that wouldn't be worse from a security
PoV than the status quo.
Such situations are the exception rather than the norm. If https is
detrimental to the
Hi,
"Use HTTPS everywhere that supports it" is simple and actionable advice
for the average person that will make them more secure.
There are
applications and sites where HTTPS doesn't really help, but other than
some unusual performance edge cases that are pretty rare in practice, it
doesn't
On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> I can confirm that if you build in split-usr mode then the generators
> are looked for only in /lib:
>
> https://github.com/systemd/systemd/blob/v247/meson.build#L156
>
> (the systemgeneratordir meson variable is set from rootlibexecdi
On Fri, 2021-08-20 at 18:30 +0100, Simon McVittie wrote:
> Control: retitle 992554 debhelper: moves systemd system generators to a
> location not searched by systemd
> Control: reassign 992554 debhelper 13.4
> Control: affects 992554 + tor ostree
>
> On Fri, 20 Aug 2021 at 16:20:04 +, Peter P
On Fri, Aug 20, 2021 at 07:56:33AM -0600, Sam Hartman wrote:
> As you know, one of the ways we can see how close we are on consensus
> is to look at what happens when someone proposes a summary like you did.
Thanks, that was my goal: trying to see if we could move the
discussion towards some kind
Control: retitle 992554 debhelper: moves systemd system generators to a
location not searched by systemd
Control: reassign 992554 debhelper 13.4
Control: affects 992554 + tor ostree
On Fri, 20 Aug 2021 at 16:20:04 +, Peter Palfrader wrote:
> It seems that generators in /usr/lib/systemd are be
On Thu, 19 Aug 2021, Luca Boccassi wrote:
> > Installing those files in /usr/lib/systemd/system is fine.
>
>
>
> This is indeed the right thing to do moving forward, so updating
> Lintian would be the best outcome. Thanks!
It seems that generators in /usr/lib/systemd are being ignored. This
c
On 2021-08-20 08:48:11 -0700 (-0700), Russ Allbery wrote:
[...]
> It sounds like we have a general consensus in this thread that,
> while changing our default to HTTPS probably won't make anything
> more secure in practice, we should still do it?
Coincident with any default change, it would probab
Jeremy Stanley writes:
> Yes, this is a much nicer way of rephrasing it, but basically still what
> I said. Turning on HTTPS by default wouldn't be addressing any
> particular user risk, it would simply keep everyone from having to
> discuss and explain it ad nauseum. Much like replacing older ha
On 2021-08-20 07:56:33 -0700 (-0700), Russ Allbery wrote:
[...]
> Do you think using HTTPS makes security worse?
[...]
No, obviously not, except insofar that instilling a false sense of
security can be harmful in the long term because it excuses people
from thinking about the actual problems they'
On 8/20/21 10:56 AM, Russ Allbery wrote:
Do you think using HTTPS makes security worse?
No idea whether I qualify as a "security expert" but as someone who has
spent a fair amount of time working in security, my concern is making
advice simple enough for people to follow. Complicated, condition
My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734
has been closed again, with no explanations.
While mailgraph was started on boot in the past, this stopped
working with the upgrade to Debian 10, and I had to enable it
again. So issues with the upgrade to Debian 11, but the ma
Jeremy Stanley writes:
> I agree with all of the above, my point was that the current state of
> HTTPS doesn't especially improve integrity for Debian package management
> over the signed indices and checksums we already rely on, and trying to
> use HTTPS for privacy/secrecy (which isn't really w
On 2021-08-20 11:36:41 +0200 (+0200), Bjørn Mork wrote:
> Jeremy Stanley writes:
>
> > While this does complicate it, a snooping party can still know the
> > site they're connecting to via SNI happening unencrypted,
>
> I believe this can be fixed with TLS 1.3?
>
> > and packet sizes/pacing lik
> "Theodore" == Theodore Ts'o writes:
Theodore> On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
>> In this specific case, I think the thing you're having a problem
>> with is the gradual, file-by-file migration of executables into
>> /usr by individual packages
On 20/08/21 7:22 pm, Nilesh Patra wrote:
> Well, I meant u-p-u and t-p-u as disconnected suites during freeze. Upload to
> u-p-u, stuff passing there migrates to t-p-u.
We already have testing-proposed-updates with a different set of rules.
See https://wiki.debian.org/TestingProposedUpdates
>
On 20 August 2021 7:00:15 pm IST, Pirate Praveen
wrote:
>
>
>On 20/08/21 4:51 pm, Nilesh Patra wrote:
>> Or, instead, if you have a u-p-u suite, and stuff that passes there migrates
>> to t-p-u,
>> this could be completely mitigated.
>
>No, that will defeat the purpose of freeze. t-p-u is tar
On 20/08/21 4:51 pm, Nilesh Patra wrote:
> Or, instead, if you have a u-p-u suite, and stuff that passes there migrates
> to t-p-u,
> this could be completely mitigated.
No, that will defeat the purpose of freeze. t-p-u is targeted at testing
without going via unstable.
If this has to happen t
Luca Boccassi writes:
> On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
>> On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
>> >
>> > I think no one likes that idea, but it's the only solution that doesn't
>> > immediately fail because it requires a dpkg update that hasn't
On 8/20/21 3:51 PM, Stephan Lachnit wrote:
> On Fri, Aug 20, 2021 at 11:03 AM Andrey Rahmatullin wrote:
>> If you mean keeping unstable as is and uploading stuff for testing into
>> t-p-u, that's was always called a bad idea, as nobody tests stuff in
>> t-p-u.
>
> If you don't change anything
On Fri, 20 Aug 2021 at 07:26:51 +0200, Helmut Grohne wrote:
> The options you present to work around this sound plausible to me, but
> they do complicate the transition plan somewhat. In essence, we'll get
> two transition points. One for non-buildds and another for them.
Maybe that, but what I wa
On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
> On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> >
> > I think no one likes that idea, but it's the only solution that doesn't
> > immediately fail because it requires a dpkg update that hasn't shipped with
> > the current s
On Fri, Aug 20, 2021 at 11:03 AM Andrey Rahmatullin wrote:
> If you mean keeping unstable as is and uploading stuff for testing into
> t-p-u, that's was always called a bad idea, as nobody tests stuff in
> t-p-u.
If you don't change anything else, then you're right. If you enable
t-p-u by default
That file is specially compiled using a different set of flags. This
is done deliberately, and is not an issue. You can squelch the false
positive using an appropriate stanza in debian/rules, to issue a
command in the log that tells blhc to stand down. Like this:
execute_before_dh_auto_build:
Jeremy Stanley writes:
> While this does complicate it, a snooping party can still know the
> site they're connecting to via SNI happening unencrypted,
I believe this can be fixed with TLS 1.3?
> and packet sizes/pacing likely give away which pages or files are
> being retrieved based on their
On Fri, Aug 20, 2021 at 11:01:08AM +0200, Stephan Lachnit wrote:
> > Problem: Currently uploading new upstream versions to unstable during
> > freeze is discouraged. It means users using unstable don't get new updates
> > and developers are forced to upload to experimental. Using experimental
>
On Tue, Aug 17, 2021 at 10:32 AM Pirate Praveen
wrote:
> Problem: Currently uploading new upstream versions to unstable during freeze
> is discouraged. It means users using unstable don't get new updates and
> developers are forced to upload to experimental. Using experimental directly
> is ris
Hi Simon,
On Thu, Aug 19, 2021 at 11:49:22AM +0100, Simon McVittie wrote:
> I agree that's a potential failure mode, although the window for regression
> is not necessarily very long (foo would have to regress after the automatic
> transition is already in place).
Yes. You phrased it better, then
47 matches
Mail list logo
