book.)
Kind regards
Philipp Kern
intermediate builds incorporate
bits of other packages and re-export them into build environments
(unlikely?) or if you need to shepherd a lot of failed builds and try to
debug what happened, then it becomes a lot more toilsome and
labor-intensive.
Kind regards
Philipp Kern
l and bump its version. ssh-h3?
Both the paper and the project are very new - so there should not be
that many things referring to it yet.
Kind regards
Philipp Kern
Package: wnpp
Severity: wishlist
Owner: Philipp Kern
X-Debbugs-Cc: debian-devel@lists.debian.org, pk...@debian.org
* Package name: nsncd
Version : 1.4.1 (plus patches[1])
* URL : https://github.com/twosigma/nsncd
* License : Apache 2.0
Programming Lang: Rust
redirected to d-d and not posted
to d-d-a.
Kind regards
Philipp Kern
with multiple conflicting systems to put configuration in and how we
merge the files when updates are installed. There would need to be some
deeper primitives to make this happen.
Kind regards
Philipp Kern
installing a syscall filter for its auth
binary and then it failed with certain PAM modules (see also your
allow_ypbind example). So we should also not be too limiting when
sandboxing daemons.
Kind regards
Philipp Kern
to manually provision IP addresses on servers.
Kind regards
Philipp Kern
^WCanonical has been doing its own development in this space as
well with netplan. Ubuntu will continue to do its own fixes to glue
things together.
Kind regards
Philipp Kern
[1] With notable exceptions like doko maintaining the toolchain - and
I'm sure I'm not crediting everyone. But that's also
.
Kind regards
Philipp Kern
to temporarily export that component
into both its own and non-free proper. That'd decouple the migration on
the user side.
Kind regards
Philipp Kern
*
# requesting: uid
#
# jwilk, users, debian.org
dn: uid=jwilk,ou=users,dc=debian,dc=org
uid: jwilk
Kind regards
Philipp Kern
r. It does pick a winner manually in the resolver
and it looks random (or rather in "apt showpkg" order). But it's not
like it didn't work.
Kind regards
Philipp Kern
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
by design - to get newer versions from experimental
if necessary.
Kind regards
Philipp Kern
[1] This might require an overall agreement across Debian at times. But
that seems to be more relevant for dependencies than build-dependencies.
different HTTP header.
If there are API clients talking to it, it might be slightly more
involving to setup - but it's not like other people haven't had to deal
with getting OIDC tokens for various APIs before. :)
Kind regards
Philipp Kern
rprising" (less surprising?) is
obviously false. "No change" is always less surprising than any change,
whatever the rationale is.
It can also be unsurprising from an end-user's perspective. For someone
new to the system. So that line of argument does not really hold.
Kind regards
Philipp Kern
of ancient server-side
implementations when the right kinds of switches are passed to it (e.g.
KexAlgorithms and HostKeyAlgorithms). I have yet to be unable to
actually connect to a target - even if it means fiddling increasingly
with flags.
Kind regards
Philipp Kern
]. I just fear that it won't actually solve your denylisting
problem at hand. People will keep not specifying it. Can't popcon go and
just accept reports for packages in the archive somehow?
Kind regards
Philipp Kern
[1] Although most might disable popcon anyway.
setup-storage is obviously better. But good
riddance to the lack of sensible debugging of the shell script horror
story that is the existing system. :)
Kind regards
Philipp Kern
herent to the design. If
you want more guarantees, you need to move from discretionary access
control (based on the identity at the time of process (tree) creation)
to mandatory access control (e.g. SELinux).
Kind regards
Philipp Kern
regards
Philipp Kern
[1] https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
(somewhat insecure)
defense in depth if we wanted to, but maybe the world just agreed that
you need to get your clock roughly correct. ;-)
Kind regards
Philipp Kern
.
Except for the security archive, where https can prevent a
man-in-the-middle from serving you outdated information and thus deprive
you from updates.
For a week until Valid-Until expires. Note that the denial of service
equally works for HTTPS, it's just more noisy.
Kind regards
Philipp Kern
On 2021-08-12 17:56, Marc Haber wrote:
On Thu, 12 Aug 2021 13:44:24 +0200, Philipp Kern
wrote:
On 2021-08-12 12:23, Polyna-Maude Racicot-Summerside wrote:
Now if people start doing stuff they don't master than it's not
privilege escalation but much more something like another
manifestation
ves.
Now of course there's value in people having this knowledge and
companies should recognize this value. But from communication and
awareness we learn, no?
Kind regards
Philipp Kern
[1] E.g. thinking of https://debian-handbook.info/browse/stable/
different, more
general problem.
Kind regards
Philipp Kern
processing for both for the maintainer and to the FTP team.
I do recall that the FTP masters would've been generally open to have
such an auto-approver (but maybe I'm wrong), but that no-one stepped up
yet to code it up?
Kind regards
Philipp Kern
a vote
process and be obstructionist than it is to upload a compromised
package. :)
Kind regards
Philipp Kern
that case (4.2.2.5).
A single person being able to block consensus of basically everyone else
feels like opening up the process to unconstructive behavior.
Kind regards
Philipp Kern
are
introduced by blindly updating debhelper compat levels - staying
at a deprecated compat level is better than a not properly tested
compat bump.
To be fair: You can assert statically if the compat bump did not
introduce any changes (by compiling twice).
Kind regards
Philipp Kern
t
makes a strong case for availability of libre firmware for wifi cards.
Especially if you care about spectral efficiency, i.e. using a shared
medium efficiently.
Kind regards
Philipp Kern
[1]
https://libreplanet.org/wiki/LinuxLibre:Devices_that_require_non-free_firmware
e question here is. You get NAT. You even get NAT to
your WiFi - i.e. you can use it as a glorified USB WiFi device (at least
with Android). I have successfully either fixed or installed Debian
through a cell phone in the past because there was no other way at hand.
Kind regards
Philipp Kern
non-free, of course, as it needs to be signed
for the most common DSPs - and cannot be rebuilt reproducibly. I guess
we are not the target here either but instead it's for vendors basing
their firmware on one common architecture. So even when we get close, we
don't seem to get all the way. :(
Kind regards
Philipp Kern
the buildd network it is also still an unsolved question how to allow
build-depending on a (small, allowlisted) subset of non-free.
Kind regards
Philipp Kern
only make that worse.
Kind regards
Philipp Kern
[1] https://cor3ntin.github.io/posts/abi/
intainers.
Given the whole source code trust story it'd be better if dak were to do
it by itself rather than relying on an external service to do it.
(Or we make it culturally allowed to do it using client-side tooling, as
long as it is a no-change-but-debian/changelog upload.)
Kind regards
Philip
for someone who
> *only* uses main to download the source, install the build dependencies,
> and successfully build the package themselves. Doing *that* must not
> require anything outside of main.
Somewhat ironically not depending on anything but main is also true for
non-free and contrib. (At least when you want it to be built by the
official builders.)
Kind regards
Philipp Kern
; (rather than not using it) - but they are free to reactivate it. It
>> feels like just checking for @debian.org is good enough, IMO.
>
> Well, DMs don't have debian.org email addresses.
Sure, but I'd expect that state to be temporary, no?
Kind regards
Philipp Kern
veryone
who got access to a debian.org email address has been an OSS contributor
of sorts. Which leaves those who opted out of the email address entirely
(rather than not using it) - but they are free to reactivate it. It
feels like just checking for @debian.org is good enough, IMO.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
e GNU which was last updated in 2015 (both tarball and
CVS) and despite GNU redirecting to a github.io page it doesn't look
like there is any more up-to-date repository of it either. So I'm not
sure if maintenance is a great argument here. Although I will note that
Archlinux does not actually patch it.
Kind regards
Philipp Kern
Package: wnpp
Severity: normal
I intend to orphan the icon-naming-utils package.
Last upstream release was 11 years ago. There is effectively no churn in
this package. It is also a required build dependency for a bunch of icon
themes:
# Broken Build-Depends:
extra-xdg-menus: icon-naming-utils
easons. That pushes the cost
elsewhere of course. On the other hand it's not the worst idea to
require signatures on all commits instead.
Kind regards
Philipp Kern
want to suggest that buying hardware is required, but
that's literally what they were designed for. Automatically dealing with
origin information sanely and then a touch signs you in. OTPs are as
fishable as passwords.
Kind regards
Philipp Kern
whitelisting code, but I think last time
someone tried a big refactoring and introduction of tests was required
of them prior to the contribution - which is a high bar after getting
dak to run properly for development purposes first.)
Kind regards
Philipp Kern
ist and rejectlist are
terms that actually describe what is happening in most contexts.
Of course communities also build up some slang to see who is "in" the
group and who is "out". But it actually makes things more accessible to
others if you describe things as they are.
Kind regards
Philipp Kern
that journalctl's (and also
systemctl status') performance reading journal files is still pretty
awful on spinning rust[1]. At times this makes me go to text logs
instead because slicing the files using tail and grep is much, much
faster.
Kind regards
Philipp Kern
[1] I think this is pretty
obs* that we
should document as the default unless there is a reason to use something
else. It does not need to be cron, though.
Kind regards
Philipp Kern
and if
those people are the most active in the project. But I don't think that
this is particularly useful distinction. For the best we know the others
did not care enough to vote (or were unable to for technical reasons)
and were thus ok with any outcome. Also we welcome people to join the
project, if they do contribut
he correct solution for
consistent versioning across all architectures. Ubuntu exclusively does
those and I still struggle how we would build such a service in Debian
without facing exactly the same concerns as tag2upload. Maybe if dak
itself would do it?
Kind regards
Philipp Kern
On 2019-10-07 13:43, Johannes Schauer wrote:
Quoting Philipp Kern (2019-10-07 13:21:36)
On 10/7/2019 1:17 PM, Shengjing Zhu wrote:
> On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
>> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
>>> Specifically, cur
apping faster rather
than trusting random binaries on the internet. (Unless we grow an
"assemble an image from debs" service on, say, ftp-master.)
Kind regards
Philipp Kern
h pointing out that Firefox's use of Cloudflare's DoH
endpoint is governed by a different policy outlined here:
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/
Per that policy, other third parties can only get the data with
Mozilla's written permissions. And APNIC (or any other third party) is
not mentioned.
Kind regards
Philipp Kern
an be addressed through wrapper scripts,
but then it's odd to anyone familiar with Debian.
Obviously I'm not bound to that format being "3.0 (native)" but some
"3.0 (dumb)" that just tars up the whole tree without caring about the
version scheme would then be nice to have as a replacement. ;-)
Kind regards
Philipp Kern
r as well as daemon options not being sufficiently tightly
speced out in native unit files. After all, you do want to give daemons
some time to stop. But at least with systemd you know when the process
has exited.
Also I mostly saw this taking a long time around deactivation of devices
(swap, crypto). (Although I question why you'd disable swap given the
consequence of getting everything back in, but alas.)
Kind regards
Philipp Kern
d you can deny service
startup, which is also what the builders do.
Kind regards
Philipp Kern
ned systemd-sysv to
> -100 to avoid repeating the last unfortunate incident where I had to drive
> to the colo facility.
You want dbus-x11 instead of dbus-user-session then, I think.
Kind regards
Philipp Kern
y have set for themselves.
Kind regards
Philipp Kern
not be universally accepted, I guess.
Kind regards
Philipp Kern
On 2019-08-07 18:51, Jeremy Stanley wrote:
On 2019-08-07 10:19:00 +0200 (+0200), Marc Haber wrote:
On Mon, 05 Aug 2019 22:29:41 +0200, Philipp Kern wrote:
[...]
> I'd still expect a Cloud/Compute provider to offer default
> images in any case that could be preconfigured appropriately.
On 2019-08-06 13:43, Bill Allombert wrote:
On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote:
And finally, the load spikes: Upthread it was mentioned that
RandomizedDelaySec exists. Generally this should be sufficient to even
out
such effects. I understand that there is a case
at I think of this in terms of systemd primitives. But the
tool was written for a reason and a lot of thought went into it.
Kind regards
Philipp Kern
bviously, I don't think it is a good idea to break this for
non-systemd users because of difficulties making it work properly
with systemd. Perhaps I have misunderstood you ?
To be honest, that's something that the compatibility/init diversity
folks then need to figure out.
Kind regards
Philipp Kern
except sometimes when the filters need to be adjusted. And as you can
see Gentoo deals with that just fine and we could accept some breakage
in unstable too, as long as the migration of the breaking library is
stopped until the fix for the dependencies is in.
Kind regards
Philipp Kern
rather than its main process. But it's also not doing the environment
cleanup AFAICS.
Kind regards and thanks for making all of us more secure! :)
Philipp Kern
would have been solved by
InRelease...
Kind regards
Philipp Kern
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926035
InRelease files (not to mention that it doubles the
traffic for no-change cases), I'm surprised they aren't using InRelease
files yet.
Given the timeline, shouldn't we also get oldstable to ship an InRelease
file?
Kind regards
Philipp Kern
will schedule in the correct order by itself.
BTW, one very important thing: are the buildds configured to use
incoming at least? If so, that probably could be bearable.
And of course buildds use incoming and so does wanna-build.
Kind regards
Philipp Kern
salute the source-only enforcement, but I really don't
think
this was thought through completely.
As long as your build-depends are properly versioned, why can't you
just
upload all the source and let wanna-build sort it out?
That'd assume that there are no circular dependencies. I take it that
they are all arch:all? (Because otherwise wanna-build would already need
to figure it out for you to build on other architectures.)
Kind regards
Philipp Kern
-rate their apps, otherwise
they disappear from the store.
Kind regards
Philipp Kern
follow upstream here and carry a patch forever.
Kind regards
Philipp Kern
you want your emails delivered. There already have been
some suggestions in this thread.
Kind regards
Philipp Kern
On 5/31/2019 11:04 PM, Luca Filipozzi wrote:
> Before you ask: an insecure hypervisor is an insecure buildd.
Are we then looking more closely at AMD-based machines given that those
had less problems around speculative attacks?
Kind regards
Philipp Kern
isservice is that we cannot standardize on a
single way so that a downstream can just pull all of them and build from
them. Instead you need humans analyzing how every single one of them works.
Kind regards
Philipp Kern
d Windows (with "Precision" drivers) now go
the way of processing the events in software only rather than having
proprietary processing in the touchpad. Once the kinks are ironed out
that should actually yield a better, more consistent experience.
Kind regards and thanks
Phil
ng the rotation/expiry of subkeys
and buildd keys. In this case the files already come from a trusted
source and should be ingested as-is, I guess? (Not that I particularly
like the fact that it's only a point in time validation.)
Kind regards
Philipp Kern
t
> non-parallel boot, but I’m sure it also affects all others.
FTR this is supposedly fixed on the main architectures featuring an RNG
in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which Ben
announced on this list[1] earlier this month.
Kind regards
Philipp Kern
[1] https://l
down in
> Policy, but since the adduser behaviour is easy to workaround (IIRC), it
> would not be required for it to happen first.
The former maintainer of the package seems to have been sympathetic to
the patch in [1], too.
Kind regards and thanks
Philipp Kern
[0] https://people.debian.org/~pkern/perm
someone think of a viable
approach on how to approach this from a policy side?
Kind regards and thanks
Philipp Kern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 27 Dec 2018 15:59:52 +0100
Source: icon-naming-utils
Binary: icon-naming-utils
Architecture: source
Version: 0.8.90-4
Distribution: unstable
Urgency: medium
Maintainer: Philipp Kern
Changed-By: Philipp Kern
Description
to these
requirements?
Just discounting that on the grounds of "that's normal for backporting"
if it's unique to your proposal is not quite satisfactory to me.
Kind regards
Philipp Kern
[1] You can make the argument that there's a problem with security
update. But that's why the urge
quickly.
Kind regards
Philipp Kern
[1] I would like to re-register my objection to that name for the same
reason Holger stated: it is confusing to reuse an older name (which, by
the way, started outside of Debian, too and was then merged in) with a
new concept.
hasn't seen
a new upstream version since 2011. And the C++ library doesn't seem to
have a CLI name claim at all.
I suppose it's mostly the point that we package all free software on the
planet that we become an arbiter of names. But we should try not to be
that if we can avoid it.
Kind regards
Philipp Kern
pendencies are bundled - if only because
you'd track upstream closely and would through that (hopefully) pull in
necessary security updates.
Kind regards
Philipp Kern
[1] And to some degree I am unhappy with backports' team's antagonistic
view on volatile here. Stuff like gitlab would have bee
ing...
Kind regards and thanks
Philipp Kern
Kern
Description:
choose-mirror - Choose mirror to install from (menu item) (udeb)
choose-mirror-bin - Choose mirror to install from (program) (udeb)
Changes:
choose-mirror (2.95) unstable; urgency=medium
.
* Team upload
.
[ Philipp Kern ]
* Update Mirrors.masterlist.
* Bump maximum
operating system.
You particularly seem to only need a Systemd operating system.
So what you want is https://www.gnu.org/software/shepherd/?
Kind regards
Philipp Kern
ts are forbidden. Just like my
introductionary statement of "but if you use a different system not
considered an init system, you are fine", there's nothing in policy
mandating periodic jobs to work in a particular way. It just talks about
what to do if you do ship a cronjob.
Kind regards
Philipp Kern
On 2018-10-16 14:36, Ian Jackson wrote:
Philipp Kern writes ("Re: Debian Buster release to partially drop
non-systemd support"):
Could someone reiterate about what the current state of init diversity
is supposed to be? Is it assumed to be best effort of every maintainer
being requir
shell script that checks for the preconditions. Would anacron and
cron need to be depended upon in that case or would they could they even
just be recommended? Both would not be needed on a default Debian system
that ships with systemd.
Kind regards and thanks
Philipp Kern
[1]
"Alternative
, the vendors could just pick some minimal base system (maybe
> apline or devuan based) [...]
That's also where you lost me, FWIW.
Kind regards
Philipp Kern
ike Go or Rust around, it
quickly approaches the point where it's not worth it anymore.
Kind regards
Philipp Kern
90x I can say that the port was driven without any commercial
interest on both Aurelien's and my side.
Kind regards
Philipp Kern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 18 Sep 2018 14:27:08 +0200
Source: python-gbulb
Binary: python3-gbulb python-gbulb-doc
Architecture: source
Version: 0.6.1-0.1
Distribution: unstable
Urgency: medium
Maintainer: Konstantinos Margaritis
Changed-By: Philipp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 21 Aug 2018 17:50:31 +0200
Source: partman-auto-lvm
Binary: partman-auto-lvm
Architecture: source
Version: 70
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed-By: Philipp Kern
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 31 Jul 2018 12:14:13 +0200
Source: partman-crypto
Binary: partman-crypto partman-crypto-dm
Architecture: source
Version: 99
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed-By: Philipp
in Debian that mechanism is called GR or appealing to the
tech-ctte and letting them vote (and then maybe another GR, hah).
Kind regards
Philipp Kern
On 18.07.2018 20:38, ju xor wrote:
> Philipp Kern:
>> On 2018-07-18 18:24, ju xor wrote:
>>> Philipp Kern:
>>>> Should this live in some kind of tor-* namespace?
>>> no
>> Without any rationale? :(
> i'm not sure what you mean, but in case
On 20.07.2018 10:18, Marco d'Itri wrote:
> On Jul 20, Philipp Kern wrote:
>> Make sure that glibc splits out libcrypt into its own package, have libc6
>> depend on it and then provide libcrypt1? (Because it's really providing
>> libcrypt's ABI from another package.) Versi
libcrypt into its own package, have
libc6 depend on it and then provide libcrypt1? (Because it's really
providing libcrypt's ABI from another package.) Versioning might be
tricky, though.
Kind regards
Philipp Kern
On 2018-07-18 18:24, ju xor wrote:
Philipp Kern:
Should this live in some kind of tor-* namespace?
no
Without any rationale? :(
Kind regards
Philipp Kern
1 - 100 of 1244 matches
Mail list logo
