On 7/9/21 4:07 AM, Jonas Meurer wrote:
> Hey Nilesh and Peymaneh,
> 
> Nilesh Patra wrote:
>> On 7/6/21 9:28 PM, Peymaneh Nejad wrote:
>>> This package[1] provides a builddependency for caddy:
>>> github.com/smallstep/cli/crypto/x509utils
>>>
>>> Initially I wanted to package the whole project, including its binary 
>>> step-cli that seems to be a very useful tool to me. I revisited my plans 
>>> and would propose to only package the library that is needed for caddy. As 
>>> of now, it excludes any sourcecode not needed for providing 
>>> github.com/smallstep/cli/crypto/x509utils to keep the dependences simple
>>>
>>> my reasoning is that the binary pulls a lot of dependencies that are forks 
>>> by the smallstep developers of other packages to suite the developers needs 
>>> (See my last RFS on this ML). A complete overview is here[1].
>>>
>>> Nilesh already wrote sometimes that they'd rather not upload forks if 
>>> avoidable. An alternative would be to apply all the patches needed for 
>>> building step-cli. . I skimmed through the source code and to me it seems 
>>> that patching the original packages could break the intended functionality 
>>> of several of the packages like zmap/zcrypto. I also fear that my novice 
>>> programming skills together with my tight schedule are not the best 
>>> situation for mangling around with code that is intended for verification 
>>> and linting of TLS certificates.
>>
>> IMO, if you can, you really should package this binary. I think the target 
>> is not to get everything in somehow, but to get all packages in excellent 
>> condition that might leave minimal scope for improvement.
>> The only problem I see here is that if at some point in time, we need 
>> smallstep-cli, then we'll have to loop via NEW queue again, which I prefer 
>> avoiding.
>> However, if you think that this is redundant, and we can just go ahead with 
>> the binary, fair enough.
> 
> While I agree with you in theory, Nilesh, I think that a more pragmatic 
> approach would be more appropriate here. On her way to get the Caddy 
> dependencies packaged, there's quite a lot of pitfalls already. And spending 
> to much time with packaging binaries that are not needed for Caddy and whose 
> usage is rather theoretical sounds like going down the rabbit hole a bit too 
> far ;)
> 
> Don't you think that packaging github.com/smallstep/cli/crypto/x509utils 
> *without* the step-cli binary as a first step would be sufficient? If someone 
> really asks for the binary because they have real usage for it later on, 
> adding the binary package and for that reason again having to pass ftpmasters 
> would be perfectly fine for me.

Alright, I agree.

> If you prefer in this particular case, I could also take over sponsorship of 
> this package.

I think I'll manage this one :-)

@Peymaneh, I fixed the copyright a little, however the bad thing is that 
autopkgtests fail because of a few missing dirs
I fixed this and uploaded.
From next time, please consider to run and fix autopkgtests at your end, before 
you ask for sponsoring
Thanks for your work!

Nilesh

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to