We decided to remove the authd package in noble for the time being.
The current implementation (in particular the one in the PAM module) is
not up to our standard in terms of quality and what we are confortable
to support in the long term. Rather than releasing as is and having
risky SRUs in the
Security review looking good (comments #23 & #21) and no required MIR
TODOs (comment #12).
Package has a team-bug-subscriber (~desktop-packages). Please move ahead
and make the seed/dependency change to pull authd into main.
** Changed in: authd (Ubuntu)
Status: Incomplete => In Progress
Hi, I reviewed the internal/adapter module as requested by SE,
everything seemed to be in order. The crypto they use seems to be
correct and the standard lib is used. The code is structured as I would
expect for an adapter.
--
You received this bug notification because you are a member of Ubuntu
I believe this issue can be set to In Progress and is ready for
promotion to main.
@didrocks, @slyon: please ping me if anything is needed from Security.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I am posting this Security MIR on behalf of Sudhakar Verma (@sudhackar)
since he is out of the office.
---
I reviewed authd 0.2.1 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
authd is a service that builds cloud based
I continued exploring this topic myself last week and was able to rely
on a tool developed for this: https://github.com/coreos/cargo-vendor-
filterer/.
This tool is not ideal in the sense that:
- it vendorize the whole content
- then, it filters by replacing entire crates based on some filtering
A centralized vendor-linter is the best longterm option. Toolchains
needs more resources before they can provide a solution (FR-6859).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2048781
Title:
We agreed during the MIR meeting that a generic tooling as part of
debhelper would be the best way, didn’t we?
See my arguments above different upstream policies in different source
packages, where if we start introducing this in a per-package base, that
would create divergences between projects.
How about a debian/rules 'vendor' target that would run the crate vendor
and then rm -rf the windows crates?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2048781
Title:
[MIR] authd
To manage
Can we try to reduce the set of unneeded vendored dependencies, similar
to how it is described here for Rust
https://wiki.ubuntu.com/RustCodeInMain ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@jibel
> can you point to the Debian Go packaging guidelines you're mentioning?
https://go-team.pages.debian.net/packaging.html
It is stated in the bug description:
"- This package violates Debian Policy. It vendorizes various Go (in vendor/)
and Rust libraries (in vendor_rust/). We are
Thanks @didrocks!
I added a comment to the upstream cargo issue based on advice from
toolchains and ~Rust [0]. This issue is also raised in ubuntu-mir [1].
I'll mention this at the next MIR meeting.
[0] https://github.com/rust-lang/cargo/issues/11929#issuecomment-1960081509
[1]
12 matches
Mail list logo
