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

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server



Hellow Alexandru,

Alexandru Mihail <alexandru.mihail2897@gmail.com> writes:

> Hello Nicholas,
>>That's ok, you don't need to find the original version.  Remember
>>that
>>it's a fork and child relationship,
>
> Yes, I'm terribly sorry, I'm familiar with the fork-child relationship
> but I still found your analogy very helpful and concise, I might
> present it to my interns (if that's O.K), thanks a lot for the
> reminder. I was extremely tired when I wrote the last e-mail.

No worries, and yes, go ahead and use that analogy :)  If you feel like
citing/attributing it to me, I'd appreciate it, but this isn't required.

> In short, considering debian-legal's input, should I mention the NCSA
> copyright notice in debian/copyright for Files: htpasswd.c, adding a
> separate License: NCSA field to clarify the provenance of said source ?

Yes, and if I remember correctly, you had figured this out by your next
email (once again, sorry for my delays in replying).

> I will fix the /patches issues  we discussed in a later commit and
> would also like to propose a mechanism for integrating PAM (Pluggable
> Authentication Modules) into mini-httpd. I am currently in the
> negotiation phase  with my employer to grant an exception for this
> particular patch in order for it to be upstreamed into debian/patches
> (since, remember, we're the de-facto upstream here) and for my code to
> become GPL licensed). PAM support (which would be toggled via a
> Makefile parameter) could provide tangible improvements for the  users
> of mini-httpd and might even increase the server's popularity. The AUTH
> mechanism in mini-httpd is arguably heavily antiquated and prone to
> DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA
> solutions to interoperate with mini-httpd almost seamlessly (such as
> Radius, TACACS+) which is becoming increasingly relevant in today's
> SSO/IoT central trust-based use cases.

Wow, that's wonderful (and unexpected) news!  I hope negotiations go well.

>>P.S. Please acknowledge: Have you read the DFSG yet, and do you
>>understand why it's important?
> Yes I have and yes I do, it is one of the main reasons I decided to
> start contributing to DebianWiki (and now mini-httpd) to begin with. :)

Thanks, much appreciated, and cool story!

>>I confirm receipt of your mail, and I see an attached signature. 
>>Where
>>can I download your public key?
>
> I'd like to ask you the same question, since I'd like to add your
> address to my keyring. I've read a bit of documentation which suggests
> using Ubuntu's HKP which seems a bit off-axis. I understand that the
> Debian Public Key Server is for DDs and DMs only (I am not yet a DM).
> I could perhaps use my DebianWiki personal page to link to my public
> key, but I do not know if that solution would be accepted or would
> sound absurd. I should find a better solution after some research.

My key is on both the Debian keyring and public servers

  https://wiki.debian.org/DebianKeyring
  https://keys.openpgp.org/
  and maybe also here
  http://pgp.mit.edu/

I haven't checked if pgp.mit.edu auto-updated from keys.openpgp.org how
it used to work with the old SKS network.

P.S. Please make create key revocation certificates for the cases:
no-longer-used, superceded, and compromised, and store them someplace
safe.

Cheers,
Nicholas

Attachment: signature.asc
Description: PGP signature


Reply to: