Topic: packaging
-
Dependency confusion: when a public package shadows a private one
If a build resolves package names across a private index and a public one, an attacker who publishes the private name publicly with a higher version can get their code installed; pip's documentation calls --extra-index-url for private packages unsafe for exactly this reason. Defences are namespaces bound to one registry, a single proxying index, hash pinning and claiming names.
-
Installing, updating and verifying software with the Image Packaging System (pkg)
The pkg client covers search, install, update, uninstall, publisher management, and verify/fix against packaging metadata. pkg operations are boot-environment aware: changes to packages that require a reboot go into a new BE activated for the next boot, while other changes apply to the running BE, under the default policy with a backup BE when kernel-affecting content is touched.
-
An internal package mirror or cache for Linux clients: apt-cacher-ng and dnf's reposync
Apt-Cacher NG caches Debian/Ubuntu packages on demand behind an HTTP proxy setting, while dnf's reposync plugin makes a full local copy of a chosen RPM repository. Both cut repeated downloads without weakening client-side signature verification, which stays on regardless of where the bytes came from.
-
Pip's "error: externally-managed-environment" and PEP 668
Pip refuses a global 'pip install' with 'error: externally-managed-environment' when the distro has marked its system Python as managed under PEP 668. The article covers what the EXTERNALLY-MANAGED marker means, the venv/pipx/apt fixes in order, and why --break-system-packages is a last resort, not a default.
Machine-readable: JSON