Bug#1040810: ITP: readpe -- command-line tools to manipulate Windows PE files
Package: wnpp Severity: wishlist Owner: David da Silva Polverari X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: readpe Version : 0.82 Upstream Contact: https://github.com/mentebinaria/readpe/issues * URL : https://github.com/mentebinaria/readpe * License : GPL-2+ with OpenSSL Exception Programming Lang: C Description : command-line tools to manipulate Windows PE files readpe is a toolkit designed to analyze Microsoft Windows PE (Portable Executable) binary files. Its tools can parse and compare PE32/PE32+ executable files (EXE, DLL, OCX, etc), and analyze them in search of suspicious characteristics. It can be used to get information from those executable files, such as headers, sections, resources and more. It also provides tools to disassemble PE files and determine their security mitigations. It is useful for application security research, digital forensics and incident response, and malware analysis. It is similar to elftools, only designed for PE files. It has more features than other more specific PE tools, such as icoextract or ntldd. This package provides the ofs2rva, pedis, pehash, peldd, pepack, peres, pescan, pesec, pestr, readpe and rva2ofs commands. This package is a newer version of the pev package (already maintained in Debian by me), as upstream renamed it to readpe. I plan to maintain it inside the pkg-security team umbrella.
Bug#1040808: ITP: golang-github-hashicorp-terraform-config-inspect -- helper library for shallow inspection of Terraform configurations
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-hashicorp-terraform-config-inspect Version : 0.0~git20230614.f32df32-1 Upstream Author : HashiCorp, Inc. * URL : https://github.com/hashicorp/terraform-config-inspect * License : MPL-2.0 Programming Lang: Go Description : helper library for shallow inspection of Terraform configurations terraform-config-inspect is a helper library and CLI tool for extracting high-level metadata about Terraform modules from their source code. It processes only a subset of the information Terraform itself would process, and in return it's able to be broadly compatible with modules written for many different versions of Terraform. . The primary way to use this is as a Go library, but as a convenience it also contains a CLI tool called terraform-config-inspect that allows viewing module information in either a Markdown-like format or in JSON format. Reason for packaging: Needed by terraform-switcher (ITP: #1014440)
Re: Second take at DEP17 - consensus call on /usr-merge matters
On Sun, 9 Jul 2023 at 22:07, Helmut Grohne wrote: > > Hi Sam, > > Thanks for trying to wrap your head around the complexity. > > On Sat, Jul 08, 2023 at 07:57:40AM -0600, Sam Hartman wrote: > > So for me, a 3C proposal would have two components: > > > > 1) An explanation of what the archive looks like at time of bootstrap > > (and changes to any bootstrap programs) so I can reason about whether > > bootstrap works. > > I hope this one is simple. > * All packages ship all of their files in canonical locations. > * base-files ships all of the aliasing symbolic links and their target >directories. > * Given that base-files installs the symbolic links, all programs are >immediately working after unpack prior to running any maintainer >scripts. > * Consequently, cdebootstrap and mmdebstrap just work without any >modification. > * An unmodified debootstrap fails (unpacking base-files due to -k). >+ We modify debootstrap such that it first unpacks and then merges. >OR >+ We stop passing the -k flag to tar. (Though we need a better > understanding for why that was added post jessie.) > > > 2) An argument of safety of upgrades focused on the changes and why > > those changes are safe both for unstable upgrades and for bookworm > > upgrades. > > As far as I understand the question here, it is about those aspects that > are specific to the 3C solution as opposed to a 3B solution. In both > cases, we move all of the files to their canonical locations. I'm not > sure whether the protective diversions for aliasing links (DEP17-M4) are > something we ultimately need in all scenarios, but in case of 3C, we > quite certainly need them to make upgrades safe, so that's an aspect to > consider here. The other aspect of course is shipping the symlinks in > base-files (DEP17-M11). So what could go wrong here? > > In an upgrade scenario from unstable or from bookworm, we'd have to > unpack and configure usrmerge-support before unpacking base-files, since > that becomes a Pre-Depends of base-files. usrmerge-support.preinst would > verify that the filesystem is merged already (much like usr-is-merged > does) except that it does not tolerate > /etc/unsupported-skip-usrmerge-conversion anymore, so any system using > that mechanism will fail this preinst. Then usrmerge-support.preinst > would install the protective diversions (DEP17-M4) on behalf of > base-files. Since these are --no-rename, the filesystem is not modified > and since we just verified that all the affected locations really are > symbolic links rather than directories, dpkg-divert wouldn't error out > about diverting a directory. In any case, usrmerge-support is eventually > configured (without a postinst), which allows unpacking base-files. > Whenever we unpack base-files (now or for subsequent upgrades), dpkg > will create each aliasing symlink with a temporary name and rename(2) it > to the final destination. Since rename(2) atomic, the aliasing symlinks > will be never go missing. When upgrading or removing any other package, > dpkg may consider removing an aliasing symlink as that package may be > the last package to ship an aliased file. When this happens, the removal > of the directory will be redirected to an innocent location via the > protective diversion. Since diversions only match exactly (they are not > meant to be used for directories), files installed "below" the diverted > aliasing links (i.e. aliased files) will be entirely unaffected by the > protective diversions and dpkg will operate on them as usual. > > The most common failure mode during upgrades seen by users likely will > be when /etc/unsupported-skip-usrmerge-conversion exists and the system > isn't actually merged. > > I have a hard time figuring out what else could go wrong here and that's > probably because I'm biased towards 3C. On the other hand, the reason > for me to like it is because I see very little that could go wrong (in > addition to what can already go wrong due to moving all the files). I > hope that others can use this detailed description of what happens to > construct possible failure cases such that we can better understand the > risk here. You have said in the original mail and on the writeup that this option requires all the affected packages to be upgraded at the same time, and in the correct order, or things will break. What happens if any of those packages are held back, for whatever reason? This is the fragility aspect that I am worried about, and that is not an issue at all if we just fix mmdebstrap to do the right thing as debootstrap already does. Kind regards, Luca Boccassi
Re: Second take at DEP17 - consensus call on /usr-merge matters
> "Timo" == Timo Röhling writes: Nod, I was wrong. Wanted to ex plicitly acknowledge that, although I think it is also obvious from other mails.
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi. I have read both of your messages over the weekend multiple times. I don't think replying point-by-point is going to be all that helpful, although if there are any cases where you'd like me to do that, I will. * I am really impressed with the work you are putting in on all this. You have done an amazing job at a really hard problem. * Mostly, I popped into this discussion to try and help confirm consensus. I think my participation has come close to outliving its usefulness. I am not involved in this problem enough to be running experiments, and I am probably not going to go dig into the guts of dpkg to start looking for problems that we might be overlooking. * The more I look at this, I think the real complexity is not in bootstrapping, but is in the rest of the proposal for canonicalizing paths. I am very uncomfortable overall; it seems complicated enough that we probably will break something somewhere. I do not see anry better options though. I think this affects things in a couple ways: * I hope we can put the bootstrapping decision behind us soon and focus on the harder problem, because I think bootstrapping is a bit of a bikeshed at this point. * I hope that we're open to better ideas of doing things proposed even fairly late in the process. If someone finds ways of removing complexity that we don't see now, I think it is worth seriously considering even if implementation has already started. * I think the bootstrapping decision may not be something we need a project consensus on. If the people involved can get to something that works for them, that's probably good enough. So, mmdebstrap maintainer, people who have worked on debootstrap recently, with no significant objections from base-files, glibc, or other major essential packages. * I think your most recent mail really helps explain 3C, and I agree that is a proposal that someone sufficiently knowledgable could evaluate for safety. I do not feel comfortable enough with my knowledge of dpkg-divert to say "looks good to me," although I am now more comfortable with 3C than I was earlier. * Mitigation M-4 introduces what appear to me to be some undesirable properties we should at least document. We appear to be depending heavily on limitations of dpkg-divert. In particular, we're depending on the idea that diversions don't work for directories. So we're introducing yet more cases where dpkg's view of the world is different than reality. We're doing more things that would make it difficult for the dpkg maintainer if they actually wanted to enhance dpkg to better understand what was going on. If dpkg wanted to support diverting directories, it would now also need to support these kind of fake protective diversions. * I specifically withdraw my concerns about changing debootstrap to move directories and create symlinks after the initial unpack. I was imagining that the complexity would be similar to usrmerge. But as you point out in your patch, removing the atomicity requirement makes things far simpler. * I think I still prefer 3B to 3C if only because it might avoid M-4 (and I think M-8 might be less problematic than M-4 at least if we can avoid protecting directories with M-8). However, if we were voting I'd rank both 3C and 3B above none of the above. I'd rank "let the people doing the work decide" well above either 3B or 3C. If there is anything else I can do to help put bootstrapping behind us at least for now and help get to a concrete proposal for canonicalizing files, let me know. I think that proposal will require as much review as we can get. --Sam signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Helmut Grohne left as an exercise for the reader: > And yeah, please work on changing that ifupdown by default. I'm faced > with having to uninstall it from more and more systems. In case, you > do a straw poll, I vote for systemd-networkd, which happens to be > installed by default. Would there be any volunteers doing the d-i > integration? I'd be interested in taking this on, though I wouldn't want to step on anyone's toes, so if someone with a feeling of ownership would rather take it, please let yourself be known. I'd want clarity as to whose approval I need to merge code (and their buy-in to the effort overall) before starting. I've messed with d-i and systemd-networkd both a good bit, and like you (I assume) believe systemd-networkd to be the best option at this time, and also moving forward. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote: > On top of that, a minimal installation chroot doesn't need a > fully-featured dhcp client. As Simon said already, busybox is there > for any reason for a minimal one. For the rest - installer and whatnot > - the installer and tasklets should pull in the required stack as > needed. I contend that currently a debootstrap includes a dhcp client and this is more of a migration from one dhcp implementation to another. Since dhcp is the most common way of configuring a network, supporting it in ifupdown by default also seems like a reasonable choice. > So I think not only we should not bump the priority of dhcpd-base, but > we should also change ifupdown's down to optional. I don't quite see consensus on this yet, but I already see significant interest in changing the default network configuration method. I hope that it is out of question that we'd demote the priority of the recommended dhcp client when demoting the priority of ifupdown. Demotion of ifupdown needs to come with a proposed replacement and/or with changes to the debian-installer. I do hope that we can get that discussion going and implemented before trixie. However, this is about changing the default dhcp client for use with debootstrap and moving the priority from one package to another seems like an incremental improvement that is not blocking the bigger goal of changing the default network configuration tool in any way. I expect that dhcpcd will not be important in trixie, but for now that move makes sense to me, because it is as easily reverted as it is implemented. This is an instance of "The perfect is the enemy of the good." And yeah, please work on changing that ifupdown by default. I'm faced with having to uninstall it from more and more systems. In case, you do a straw poll, I vote for systemd-networkd, which happens to be installed by default. Would there be any volunteers doing the d-i integration? Helmut
