S classes, which
means the base of people who know at least some Python is probably larger
than any other language filling the same niche.
I think the only real competitor to Python today on the popularity and
existing knowledge front would be JavaScript, and I think it's less
suitable for the
implications (I think the
permissions are more precautionary, and it's also fairly unlikely that
anyone will have installed krb5-wallet before krb5-kdc), although Sam,
please let me know if you think I'm wrong.
krb5-wallet has never been in a stable release, so no worries about stable
fixes.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ory. They're all released under GPL 2 or any later
version, so feel free to do anything you would like with them.
I also mailed the Debian Games Team to let them know that I was stepping
down in case were interested in picking up the package.
--
Russ Allbery (ea...@eyrie.org)
o provide assistance.
Thank you for the excellent software! I've gotten many hours of enjoyment
out of it over the years. Also thank you for being an excellent upstream
for packaging and for all of your helpful responses to my questions and
various mistakes and confusions.
--
Russ
Package: wnpp
Severity: normal
X-Debbugs-Cc: gn...@packages.debian.org, r...@debian.org
Control: affects -1 + src:gnubg
I intend to orphan the gnubg package. The package is in good shape, but
I rarely use it and am not the best person to continue to maintain it.
The package description is:
GNU B
Package: wnpp
Severity: normal
X-Debbugs-Cc: gn...@packages.debian.org, r...@debian.org
Control: affects -1 + src:gnubg
I intend to orphan the gnubg package. The package is in good shape, but
I rarely use it and am not the best person to continue to maintain it.
The package description is:
GNU B
tring ends with three double quotes, but it's better
to think of it as one escaped double quote, which is written as "", and
then the double quote that ends the argument.
This should then produce the output that you want.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
uotes, and then the double quotes within that
double-quoted string have to be escaped, which *roff does by doubling
them. So:
.CW """$ echo foobar"""
With only two double quotes, I think *roff parses that as an empty string.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Otto Kekäläinen writes:
> On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote:
>> On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote:
>> [...]
>>> I think a shallow clone of depth 1 is sufficient, although that's not
>>> sufficient to get the correc
d
rather continue down the path of providing Debian tools and processes that
reduce the delta between how Debian packaging uses Git and how most free
software development uses Git.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
much to say about this unless we need
some mechanism for labeling such packages other than a MR to Lintian. The
important information is the list of packages that shouldn't be used this
way, and the hard part is probably gathering that list.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ed debian/unstable
and debian/experimental.
Personally, I use debian/unstable but do experimental development in that
same branch if it's "targeting unstable," which is either the best or
worst of both worlds, depending on your perspective.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
sensus. We
require a minimum number of seconds to ensure that a change has been
properly reviewed by someone, but it's not a vote. If there is
disagreement over the change, it's the responsibility of the Policy
Editors to decide the best way to move forward (including asking the
Techn
ately exit with no changes to the commit message, and to do that we
probably need to write down what those expectations are. I think the
Policy language was written in a time where we just assumed there was an
obvious way for editors to behave that didn't include things like
backgrounding the
Russ Allbery writes:
> Sure, no problem. I'll file a bug against dash.
#1007263 had already been filed and was on a very similar topic, so I have
added some supplemental information to that bug report.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Sure, no problem. I'll file a bug against dash.
#1007263 had already been filed and was on a very similar topic, so I have
added some supplemental information to that bug report.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Sure, no problem. I'll file a bug against dash.
#1007263 had already been filed and was on a very similar topic, so I have
added some supplemental information to that bug report.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: dash
Version: 0.5.12-9
Followup-For: Bug #1007263
X-Debbugs-Cc: r...@debian.org
This topic came up in Policy bug #1074014. It sounds like there is a plan
to document the transition in the release notes, but, going forward, the
mechanism to change the shell underlying /bin/sh sounds like i
f files in the data.tar of a .deb. All of the protective
> diversions that we ever installed for DEP17 are managed in maintainer
> scripts and dh_movetousr does not touch maintainer scripts at all.
Ah! Thank you.
> Your reasoning makes sense to me. I do not intend to work on this
> matter, b
f files in the data.tar of a .deb. All of the protective
> diversions that we ever installed for DEP17 are managed in maintainer
> scripts and dh_movetousr does not touch maintainer scripts at all.
Ah! Thank you.
> Your reasoning makes sense to me. I do not intend to work on this
> matter, b
f files in the data.tar of a .deb. All of the protective
> diversions that we ever installed for DEP17 are managed in maintainer
> scripts and dh_movetousr does not touch maintainer scripts at all.
Ah! Thank you.
> Your reasoning makes sense to me. I do not intend to work on this
> matter, b
il dpkg can gain full understanding of the path aliasing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
il dpkg can gain full understanding of the path aliasing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
il dpkg can gain full understanding of the path aliasing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
int to bash directly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
int to bash directly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
int to bash directly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ere are two occasions where this could be seen as having been vetted.
> One is elaborate discussions on d-devel with consensus summaries that
> have not been objected to. The other is a transition bug that has been
> acknowledged by the release team. In any case, I do not think w
ere are two occasions where this could be seen as having been vetted.
> One is elaborate discussions on d-devel with consensus summaries that
> have not been objected to. The other is a transition bug that has been
> acknowledged by the release team. In any case, I do not think w
ere are two occasions where this could be seen as having been vetted.
> One is elaborate discussions on d-devel with consensus summaries that
> have not been objected to. The other is a transition bug that has been
> acknowledged by the release team. In any case, I do not think w
at needs to be
analyzed and appropriately addressed, but in the typical case, no, the
files in the packages should move so that we get to the more predictable
and easier-to-reason-about end state that was the goal of the migration
fix adopted by the CTTE.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
at needs to be
analyzed and appropriately addressed, but in the typical case, no, the
files in the packages should move so that we get to the more predictable
and easier-to-reason-about end state that was the goal of the migration
fix adopted by the CTTE.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
at needs to be
analyzed and appropriately addressed, but in the typical case, no, the
files in the packages should move so that we get to the more predictable
and easier-to-reason-about end state that was the goal of the migration
fix adopted by the CTTE.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
x27;m guessing that you're anticipating some problem related to
diversions, but I can't put the pieces together without some more details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
x27;m guessing that you're anticipating some problem related to
diversions, but I can't put the pieces together without some more details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
x27;m guessing that you're anticipating some problem related to
diversions, but I can't put the pieces together without some more details.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
you're using any
mechanism other than the simple password ones. See Authen::SASL::Perl:
As for server support, only *PLAIN*, *LOGIN* and *DIGEST-MD5* are
supported at the time of this writing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
you're using any
mechanism other than the simple password ones. See Authen::SASL::Perl:
As for server support, only *PLAIN*, *LOGIN* and *DIGEST-MD5* are
supported at the time of this writing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
one aspect of the
lifecycle, but still does not achieve the semantics you're arguing for in
the abstract.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
one aspect of the
lifecycle, but still does not achieve the semantics you're arguing for in
the abstract.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon McVittie writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>
Simon McVittie writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>
ling release with very
substantial caveats and limitations.
I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.
> On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote:
>> Well, it's related to your example of the zoom
ling release with very
substantial caveats and limitations.
I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.
> On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote:
>> Well, it's related to your example of the zoom
e use codenames in the archive structure and I am probably
overthinking this.
> What do you mean?!! It's right there!
> https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=
> ...ok, ok, it's there now because I just merged it and regenerated the
> docs :-P
Thanks! This looks good to me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e use codenames in the archive structure and I am probably
overthinking this.
> What do you mean?!! It's right there!
> https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=
> ...ok, ok, it's there now because I just merged it and regenerated the
> docs :-P
Thanks! This looks good to me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Right now, it
requires substantial effort to read any thread that you have replied to
because I have to brace myself for judgmental, emotionally loaded, and
hostile-sounding language that gets in the way of understanding the root
disagreement and having a cordial and constructive collaboration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Right now, it
requires substantial effort to read any thread that you have replied to
because I have to brace myself for judgmental, emotionally loaded, and
hostile-sounding language that gets in the way of understanding the root
disagreement and having a cordial and constructive collaboration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ssion.
I did review the discussion #1021663 in the hope that I would find a
detailed technical proposal there, but your messages to that bug seemed to
focus on criticisms of the current behavior mixed with insults. I wasn't
able to find a proposal, but it's entirely possible I missed it.
ssion.
I did review the discussion #1021663 in the hope that I would find a
detailed technical proposal there, but your messages to that bug seemed to
focus on criticisms of the current behavior mixed with insults. I wasn't
able to find a proposal, but it's entirely possible I missed it.
Howard Chu via Discussion list for the autoconf build system
writes:
> Russ Allbery wrote:
>> Many years ago when I did work on this for INN to make heavier use of
>> mmap for its new (at the time) overview system, calling msync() after
>> changes to a MAP_SHARED mapping w
uld have been
in the days of NFSv3 (if not NFSv2 in places).
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
in to the community than I am.
If folks would be willing to take a look at that issue, particularly folks
who were involved in some of these previous discussions, and let me know
if I have completely misunderstood or am barking up entirely the wrong
tree, I would greatly appreciate it.
Thank you
Porting/Maintainers.pl
Log Message:
---
Remove CUSTOMIZED element for podlators
To prepare for sync with cpan.
Commit: 3c9d78c0eb151a4917a98f20de4b2bd603dbef05
https://github.com/Perl/perl5/commit/3c9d78c0eb151a4917a98f20de4b2bd603dbef05
Author: Russ Allbery
Date: 2024
paths:
M Porting/Maintainers.pl
Log Message:
---
Remove CUSTOMIZED element for podlators
To prepare for sync with cpan.
Commit: 9647a2a6695b0f821a3d09a5992d554b18596dc9
https://github.com/Perl/perl5/commit/9647a2a6695b0f821a3d09a5992d554b18596dc9
Author: Russ Allbery
Package: dh-debputy
Version: 0.1.43
Severity: normal
X-Debbugs-Cc: r...@debian.org
Module::Build, one of the common build systems for Perl modules, defaults
to installing Perl modules under /usr/share/perl5 read-only (mode 0444).
With debhelper, this could be ignored for Debian packaging, since
dh
paths:
M Porting/Maintainers.pl
Log Message:
---
Remove CUSTOMIZED element for podlators
To prepare for sync with cpan.
Commit: 4081ca2295189846510cf1a1c455a5097eece4d0
https://github.com/Perl/perl5/commit/4081ca2295189846510cf1a1c455a5097eece4d0
Author: Russ Allbery
eyrie.org/~eagle/software/podlators/>
This package is maintained using Git; see the instructions on the above
page to access the Git repository.
Please let me know of any problems or feature requests not already listed
in the TODO file.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
maintained using Git; see the instructions on the above
page to access the Git repository.
Please let me know of any problems or feature requests not already listed
in the TODO file.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~|| 0gFzD gD,
maintained using Git; see the instructions on the above
page to access the Git repository.
Please let me know of any problems or feature requests not already listed
in the TODO file.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~|| 0gFzD gD,
Adam Majer writes:
> On 7/7/24 21:53, Russ Allbery wrote:
>> I consider it an ethical obligation as someone who works in security to
>> object whenever people make these types of absolute statements about
>> security properties. Security is almost always a trade off. Y
NULL)
> +return errno;
> +
> +while ((entry = readdir(d)) != NULL) {
> (...)
readdir ordering is probably bad. I think that's essentially random on a
lot of file systems, and I'm not sure it's even guaranteed to be stable.
Is there any chance we could get that
and there's still the
basic problem that we can't guarantee that the include directive is
present.
> I was thinking about a breaks, as in, new krb5-config would break old
> heimdal.
Ah, yes, that makes sense. And then packages that need configuration
snippets can depend on the
not required to solve my problem in a separate
package. :) I was just hoping that it would.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ly before including
them, so that there's some predictable order for which fragments override
each other? We'll want to document the ordering.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
c Kerberos
implementation, so I don't know how to represent this as a dependency.
And what dependency should a package that wants to use included
fragments have to ensure that those included fragments are loaded?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uot; specifically:
https://docs.python.org/3/library/fractions.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uot; specifically:
https://docs.python.org/3/library/fractions.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uot; specifically:
https://docs.python.org/3/library/fractions.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ecedence to LICENSES
over COPYING and picking up the copy of the MIT license in that file.
Automatically detecting license information in any complicated scenario is
probably impossible, so it would be nice if GitLab had some way to
override the automatically-detected license. If it does, I hav
y is almost always a trade off. You can
usually get more security by trading off functionality, up to the obvious
end point of securing a computer by turning it off. The best point to
occupy on that trade-off curve is a hard question that always involves
more factors than only security.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ion numbers that are much
smaller. In other words, to quote policy, "situations where the upstream
version numbering scheme changes." Yes, in this case it was only in their
packages and not in their software releases, but that still counts when
they have an existing user base that has those packages installed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
If some new attack implementation on SHA1 appears, that isn't detected
> by your SHA1CD variant, your validation can be by-passed.
This is true.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
undant (I think they're
both signed by t2u since presumably they're in *.changes).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Aigars Mahinovs writes:
> On Sun, 30 Jun 2024 at 17:58, Russ Allbery wrote:
>>> The second file consists of a shallow git clone of the repository for
>>> the tag that t2u wants to upload, put into an appropriately named
>>> tarball.
>> Just to double chec
> requirements as the thing proposed here. (Summarized as detached
> signature from the DD/DM over the tree of the tag, and that tree/tags
> data available in a file beside the upload).
Oh, yeah, for sure, none of the details now should block future
improvements worked out in the normal way.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> As soon as I start using tag2upload, I am no longer running dgit locally
> and that patch generation will be represented in the Git tree that I
> sign to trigger tag2upload.
That patch generation will *not* be represented in the Git tree that I
sign to trigger t
ign to trigger
tag2upload.
Ian explained all of this in an excellent and comprehensive message that
he sent in reply to mine, correcting my misunderstandings about how this
workflow worked. (Hopefully I have it right now!)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2uplo
Ansgar 🙀 writes:
> On Thu, 2024-06-27 at 09:15 -0700, Russ Allbery wrote:
>> *As soon as* you indicated that there was some willingness to move your
>> position, people reinvested substantial effort into trying to have that
>> discussion
> Yes, I remember. For examp
ly about Debian at all.
If you think there's something more to discuss that would help you change
your mind, the GR isn't happening tomorrow. But there has to be an end in
sight. Doing things in Debian cannot be an endless series of procedural
hoops, beyond which is simply more procedural hoops.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon Richter writes:
> On 6/27/24 00:41, Russ Allbery wrote:
>> The second case seems fine with tag2upload? Particularly if upstream
>> signs the Git tag. Instead of pointing to a possibly signed release
>> tarball, the tag2upload tag points to a signed upstream Git tag.
cess for one reason or
another. But there are a lot of upstreams for which this is not the case.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Jun MO writes:
> Russ Allbery writes:
>> For the third purpose, I believe only weak intent information can be
>> derived from the uploader signature today. It is common practice in
>> Debian to verify the Git tree that one wants to upload, run a package
>> build step
r the thing
that happens approximately never. The attacker knows all of this, and
will choose their attack strategy accordingly.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ll that my contribution to this thread accomplished was to
demonstrate that I set up sbuild years ago based on a wiki article for
btrfs and don't know what I'm talking about. :) Apologies for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
n access the base via the
> source: names.) I never liked the type=file stuff, as it's slow to
> setup and maintain.
Ah, thank you, I didn't realize that existed. That sounds like a nice
generalization of the file system snapshot approach.
--
Russ Allbery (r...@deb
tho...@goirand.fr writes:
> On Jun 25, 2024 5:50 PM, Russ Allbery wrote:
>> The tag2upload proposal moves the source package build from 1 to 2.
> NO ! That is NOT what you are proposing. There's been a 10 years long
> effort to have package reproducibility, your proposal i
job to update the source subvolume
daily to ensure that it's fully patched.
Unfortunately, there's no way that we can rely on this, but it would be
nice to continue to support it for those who are using a supported
underlying file system already.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e correct
me if I have this wrong.) My recollection is that the source package
build is normally done outside sbuild and then copied into it.
> I'm opposed to trusting only a signed git tag in your proposed
> implementation, when it has been proven we can do much better.
"Proven&qu
Russ Allbery writes:
> HW42 writes:
>> And, if yes: Why wouldn't they do the equivalent with the sources in
>> git (work on the less trusted system, transfer commits (git push/pull)
>> to the system with signing access and sign there, without review)?
> They wi
HW42 writes:
> Russ Allbery:
>> For the third purpose, I believe only weak intent information can be
>> derived from the uploader signature today. It is common practice in
>> Debian to verify the Git tree that one wants to upload, run a package
>> build step, and then
HW42 writes:
> Russ Allbery:
>> This attack is not equivalent to compromise of the uploader's OpenPGP
>> key, which neither upload architecture defends against. Many Debian
>> uploaders build source packages on less-trusted systems where they also
>> build and tes
keep message/rfc822 for better display of forwarded
mail. I am making the assumption that the recursive expansion of the
included message will apply the same rules as the outer message.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
rly if they are ongoing (in other words, not just on initial
upload, but periodically pulling all the source packages in the archive
and reproducing them again).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s worth noting for comparison purposes that a compromise of a binary
buildd is even harder to detect, since it leaves no trace in the archive
at all apart from the malicious binary package.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hat are automatically previewed. (This part I have not
tested.)
There are probably other ways to do this; those are just the ones that I
found.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Scott Kitterman writes:
> On Sunday, June 23, 2024 11:43:47 AM EDT Russ Allbery wrote:
>> You are entitled to believe that my analysis is wrong. You are not
>> entitled to claim that I didn't do the work that I did, quite publicly
>> and openly, right here on this ma
Scott Kitterman writes:
> On Sunday, June 23, 2024 11:48:09 AM EDT Russ Allbery wrote:
>> As mentioned in the summary, I believe we've found a resolution to this
>> problem provided that the FTP team is willing to implement the protocol
>> I described in dak, which A
binary buildd:
start from an independently-verified maintainer-signed thing and produce a
build artifact.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
1 - 100 of 4226 matches
Mail list logo
