Bug#1067093: Impacket Patches for PR 1714 and 1715
Arslan M. CRTO, GWAPT, OSCP Hi again, #1721 has been merged. Can the impacket package be updated to the latest state of the repository to allow the Kali Team and me to package NetExec? Thanks! On Friday, March 22nd, 2024 at 10:42, Arszilla wrote: > A small status update: > - https://github.com/fortra/impacket/pull/1714 has been merged, thus any > patch related to this is now redundant. > - https://github.com/fortra/impacket/pull/1715 has been redirected to > https://github.com/fortra/impacket/pull/1721 which is pending approval. > > As a result, once #1721 is merged, I'll be updating this ticket again to ask > you to update the impacket's package instead of applying patches. > > Kind regards.
Bug#1067093: Impacket Patches for PR 1714 and 1715
A small status update: - https://github.com/fortra/impacket/pull/1714 has been merged, thus any patch related to this is now redundant. - https://github.com/fortra/impacket/pull/1715 has been redirected to https://github.com/fortra/impacket/pull/1721 which is pending approval. As a result, once #1721 is merged, I'll be updating this ticket again to ask you to update the impacket's package instead of applying patches. Kind regards.
Bug#1067093: Impacket Patches for PR 1714 and 1715
Package: impacket Version: 0.11.0-2 Hi there, Currently, I am helping the Kali Team to package NetExec (https://github.com/Pennyw0rth/NetExec) as per https://bugs.kali.org/view.php?id=8533. NetExec (nxc/netexec) is a fork of crackmapexec (which has been discontinued) and is still in active development. Sadly, packaging netexec is not simple as it requires me to solve several dependency issues, one of which is impacket/python3-impacket. Currently, NetExec is using a fork of Fortra/SecureAuthCorp's impacket, which was created due to several functionality-breaking changes that were implemented by Fortra without regard to how they might impact the users of their library. I have discussed the situation with some maintainers of NetExec, explaining the choices I have regarding facilitating the packaging of their tool as a mere volunteer/contributor. After discussions and research that lasted days, it was concluded that there are two options available: 1. Submit PRs to Fortra and hope the changes they introduced are reverted, alongside the additions that the netexec devs have made. The netexec devs have submitted 2 PRs, https://github.com/fortra/impacket/pull/1714 and https://github.com/fortra/impacket/pull/1715. If these are approved by Fortra, the python3-impacket package would need to be updated subsequently with the changes so that packaging could continue. 2. Create a new package of the fork named python3-impacket-nxc, which would install the forked impacket library to /usr/lib/python3/dist-packages/impacket_nxc/ and proceed with packaging. However, since netexec maintainers want to be able to pull the changes from the mainstream with little-to-no manual intervention, a patch must be generated (which I did generate) that would replace all relevant instances of impacket (such as "from impacket import X") with impacket_nxc (to make sure the new package would be installed in a new path and unique namespace to avoid collisions). However, this patch is over 6700 lines and modifies ~260 files, thus even if it was split into multiple files, it might be a pain to maintain and update. After discussing these 2 options, it was concluded that a 2nd impacket package might lead to confusion on both the maintainer (Kali Team/me) and the end-user sides; hence, the netexec maintainer submitting PRs to accommodate Option #1. However, Fortra is slow to respond to PR requests at times. As a result, I wanted to question the possibility of using patch files for the 2 MRs introduced by the netexec maintainers, allowing me to continue packaging netexec without the need for a second impacket package. If this is acceptable on your end, I'd sincerely appreciate it if you could guide me through the process of providing you with the patch files, as I am fairly new to reporting these types of issues to the Debian side of things. Kind regards.
Bug#1062641: live-build Removes User Packages Installed via Hooks
Hi again, I forgot to mention that I have been installing 1Password using the commands that 1Password provided on their support page instead of the Debian Package. However, I realized I had missed the debsig-verify step. As a result, I modified my hook to look like the following: > #!/bin/bash > set -e > # Create a temporary user, because otherwise 1Password will break the Live > System: > # Refer to: > https://gitlab.com/kalilinux/build-scripts/live-build-config/-/issues/63 > useradd --no-create-home --user-group --uid 1000 tmpuser > # Add 1Password's GPG key and repository: > curl -sS https://downloads.1password.com/linux/keys/1password.asc | gpg > --dearmor -o /usr/share/keyrings/1password-archive-keyring.gpg > echo 'deb [arch=amd64 > signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] > https://downloads.1password.com/linux/debian/amd64 stable main' | tee > /etc/apt/sources.list.d/1password.list > # Add the "debsig-verify" policy: > mkdir -p /etc/debsig/policies/AC2D62742012EA22/ > curl -sS https://downloads.1password.com/linux/debian/debsig/1password.pol | > tee /etc/debsig/policies/AC2D62742012EA22/1password.pol > mkdir -p /usr/share/debsig/keyrings/AC2D62742012EA22 > curl -sS https://downloads.1password.com/linux/keys/1password.asc | gpg > --dearmor --output /usr/share/debsig/keyrings/AC2D62742012EA22/debsig.gpg > # Install 1Password: > apt-get update > apt-get install -y 1password > # Delete the temporary user: > userdel tmpuser Despite this, I can see that `1password` is listed for removal in the `filesystem.packages-remove` in the brand new ISO I have generated with this change (alongside some of the other packages I have listed). This can be seen in the following paste: https://paste.debian.net/1306346/ I have also realized I have provided a wrongful statement about Tailscale upon examining that `filesystem.packages-remove`: It is indeed written for removal. Thus, I kindly ask you to disregard my previous statement regarding Tailscale. Kind regards, Arszilla On Monday, February 5th, 2024 at 10:16, Arszilla wrote: > Hi Roland, > > First off, I'd like to let you know that your first email appeared (in my > inbox). despite it not appearing on the website. So be rest assured :) > > > I still think that removing all live-related packages in the installer is a > > good idea. The processing of 'live/filesystem.packages-remove' shows where > > the package management system has been circumvented. > > > I get that this is totally up to you. However, if people use `live-build` in > the same manner as I do, they may face this issue and may be dissatisfied. I > came up with a "tempfix" on my end by implementing a `.binary` hook that > removes `filesystem.packages-remove` if it detects its presence on the ISO > since the packages I install end up there. > > I should mention that this issue is not 1Password-specific. We initially > discovered the presence of this behavior in > https://gitlab.com/kalilinux/build-scripts/live-build-config/-/issues/61 - > where another user reported that their custom packages were being removed. > > I think when I tried installing 1Password with the commands listed in > 1Password's article, I had a similar result. I may have to check again. > However, as per my previous statement, this issue affects more packages other > than 1Password. > > In my testing, I have noticed that this issue affects the following > packages/programs I installed in my custom ISO: > - Docker (installed from Docker's own repositories) > - Tenable Nessus > - Insomnia (https://insomnia.rest) > - Spotify > - ProtonVPN > - Obsidian (https://obsidian.md) > - Visual Studio Code > - Discord > > These are just some of the packages I can remember off of my head. A small > excerpt from the `syslog` found on `/var/log/installer/` directory lists > these in more detail: > > > Jan 16 16:29:36 in-target: The following packages will be REMOVED: > > Jan 16 16:29:36 in-target: 1password* code* containerd.io* discord* > > docker-buildx-plugin* docker-ce* > > Jan 16 16:29:36 in-target: docker-ce-cli* docker-ce-rootless-extras* > > docker-compose-plugin* > > Jan 16 16:29:36 in-target: gir1.2-nm-1.0* gnupg2* insomnia* > > libcairo-script-interpreter2* libgtk-4-1* > > Jan 16 16:29:36 in-target: libgtk-4-bin* libgtk-4-common* > > libgtk-4-media-gstreamer* libnma-gtk4-0* > > Jan 16 16:29:36 in-target: libslirp0* libvulkan1* mesa-vulkan-drivers* > > multiviewer-for-f1* nessus* > > Jan 16 16:29:36 in-target: network-manager-openvpn* > > network-manager-openvpn-gnome* pigz* > > Jan 16 16:29:36 in-target: proton-vpn-gnome-desktop* proton-vpn-gtk-app* >
Bug#1062641: live-build Removes User Packages Installed via Hooks
/gitlab.com/kalilinux/packages/live-build/-/blob/kali/master/debian/changelog?ref_type=heads there are only minor adjustments to the version in Debian and Kali aimed at addressing some firmware or GRUB related issues/differences. > Please add such command to the bug report, so I can update the live-manual to > address such use case. I don't really understand what you meant with this statement. If you could elaborate a bit further, I'd sincerely appreciate it. Kind regards, Arszilla On Sunday, February 4th, 2024 at 18:59, Roland Clobus wrote: > On 04/02/2024 17:41, Roland Clobus wrote: > ... > > > echo 'deb [arch=amd64 > > signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] > > https://downloads.1password.com/linux/debian/amd64 stable main' > > > config/includes.chroot_before_packages/etc/apt/sources.list.d/1password.list > > > And I'm certain that there is a more secure way, that ensures that only > the package called '1password' will come from this repository. > The bug report was based on a kali version of live-build, so I assume > you know better than me how to do so. > Please add such command to the bug report, so I can update the > live-manual to address such use case. > > With kind regards, > Roland Clobus
Bug#1062641: live-build Removes User Packages Installed via Hooks
Package: live-build Version: 1:20230502+kali3 When users install `.deb` packages that are not available in Debian via a `.chroot` hook (such as `1password`), the `./live/filesystem.packages-remove` file in the generated ISO uninstalls the packages installed via `.chroot` after the system is installed. This was not the case until this action (which was added 12 years ago) became active a year ago: - https://salsa.debian.org/installer-team/live-installer/-/commit/ad0ebaad - https://salsa.debian.org/installer-team/live-installer/-/commit/ca1e1706757ecc9a4cf1fa5c637d5a9b513acee6 Because certain packages cannot be installed without `.chroot` hooks, I recommend reverting this change. It was discussed that users should drop their `.deb` packages to the `packages.chroot` directory instead, as that is the intended way. However, certain programs such as `1Password`, `docker` (from Docker's repositories), ProtonVPN, etc. only use the `.deb` packages to add their repos to the system and not install packages, which require users to `sudo apt update && sudo apt install -y `. This was detected during a Kali Linux live-build: - https://gitlab.com/kalilinux/build-scripts/live-build-config/-/issues/61 - https://gitlab.com/kalilinux/build-scripts/live-build-config/-/merge_requests/33
