[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [notaryproject/notary] arm64 self-check failures: runtime: marked free object in span 0xffff5ec83ac0, elemsize=208 freeindex=3 (bad use of unsafe.Pointer or having race conditions? try -d=checkptr or -race) (Issue #1708)



On Tue, Mar 4, 2025, 10:56 Simon Josefsson <simon@josefsson.org> wrote:
Tianon Gravi <tianon@debian.org> writes:

> On Tue, Mar 4, 2025, 06:13 Simon Josefsson <simon@josefsson.org> wrote:
>
>> Nicolas Peugnet <nicolas@club1.fr> writes:
>>
>> > As the tracker reports it, notary is an important piece of the Go
>> ecosystem:
>>
>> That fact together with the state of that upstream project is a bit sad.
>> Last public release in 2018 and no closed issues/pullrequests in over a
>> year now.
>>
>
> https://github.com/notaryproject/.github/issues/70 is a very relevant link
> on this point 🙈
>
> IMO we should be patching notary support out of dependent projects in
> Debian (and upstreams too).

Sounds good to me -- but I wonder if all the dependent projects still
build without notary?  I suppose one should go through them all trying
to see how critical its usage is...

In Docker, it's an optional feature called "Docker Content Trust" and has been disabled by default since it was added, and I'd wager usage is extremely low. 

Upstream should drop the functionality (especially but not only because it's dependent on a dead upstream), but we could patch out the feature completely. 

(However, given freeze timelines, it might be a bit late to attempt that right now and we should focus on getting it building successfully so all these dependent things can stay in Trixie.)

❤️,
- Tianon

Reply to: