[Judd, I couldn't find a better place to send this, so email it is]

Hi,

janning wrote:
> My wishlist:
>   
First of all, bugs should be individual items, not lists, since this way
it becomes pretty hard to mark a single item in a list as "dealt with"
and the maintainer (me) loses overview. Please refrain from this sort of
bug report in the future. Instead, feel free to report multiple bugs at
once, if necessary.

> - knockd should support ascii encoded knock sequences. each 
>   character is converted to the corresponding port of its ascii decimal value
>   example:
>   sequence = open_sesame
>   equals to
>   sequence = 115,101,115,97,109,101
>
>   this way you can use more complex port sequences which are still memorable
>   
I can't speak for upstream (Judd), but this doesn't sound very
practical. You'd be limiting the number of available ports drastically
and therefore proportionally reducing security. Not only that, but the
ports would all be mapped to relatively low numbers.
I'm not gonna tag it "wontfix", but I'd say there's a low probability of
it being implemented.

>  
> - knockd should support a max_client directive. Only this amount of knocks 
> are allowed.
>   if you have only one admin knocking, you can set max_clients=1 
>   so you are sure only one client can open a port at a time. this makes 
> knockd even safer.
>   

knockd doesn't have the concept of "client" because there's no ongoing
connection between the knocker and knockd, only individual packages.
This could be implemented if we recorded a list of IPs which opened the
port, but the change would be non-trivial (which doesn't mean it would
be hard) and even so we'd only see IPs, so multiple people behind NATs
would still be able to benefit from the open port (current situation). I
do see the use for this, but don't plan on implementing it myself
anytime soon.
OTOH, if you meant implementing the whole concept of connection in
knockd, then things get significantly more complicated...


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to