CryptoCard support broken on AMD64

2013-05-07 Thread Matthias Pitzl
Hi!

I think the support for CryptoCards is broken on AMD64.
The diff below fixes it again.

Greetings,
Matthias



--- libexec/login_token/token.c Sun Jan 13 22:21:17 2013
+++ libexec/login_token/token.c Mon May  6 15:28:17 2013
@@ -63,7 +63,7 @@
 typedefunion {
DES_cblock  cb;
charct[9];
-   unsigned long   ul[2];
+   uint32_tul[2];
 } TOKEN_CBlock;
 
 /*



Re: CryptoCard support broken on AMD64

2013-05-07 Thread Ted Unangst
On Tue, May 07, 2013 at 11:13, Matthias Pitzl wrote:
 Hi!
 
 I think the support for CryptoCards is broken on AMD64.
 The diff below fixes it again.

Very good!



Re: ftpd log address format

2013-05-07 Thread Martijn van Duren

On 05/05/13 16:18, Stuart Henderson wrote:

On 2013/05/05 10:06, Nick Holland wrote:

On 05/04/13 01:57, Ted Unangst wrote:

On Sat, May 04, 2013 at 07:26, Martijn van Duren wrote:

For a lot of cases this isn't a problem. But there are a couple of
instances where the domain name resolves to something a little to
generic to be useful to determine it's origin and hence I'm not able to
decide if it's a legit connection or not, let alone being able to place
it in my firewall.
To fix this for myself I made this minor patch to retrieve the ip
address instead of the the reverse lookup. This appears to be the same
behavior as sshd shows.


I think this is wise. Reverse lookups are not really useful imo. If
someone cares, they can always do them later.



regarding the concept, not the patch...agreed.

I have OFTEN wished I had the raw IP address in a log, I've rarely (I
want to say never) wished I had a reverse DNS lookup.


The hbuf buffer has more then enough room for the ip-notation with 256 
bytes and it's the simplest alteration I could think of.
I'm relatively new to OBSD and C-programming. So what kind of patch 
would you agree to and/or what is specifically wrong with this patch?




Nick.



I don't feel too strongly about it but my preference would be to
log both. There are circumstances (e.g. dhcp with dynamic dns updates)
where it's useful to have the reverse at the time of connection.



I could be wrong, but shouldn't those addresses/hostname translations be 
in the (dhcp server) logs?
Furthermore it could be possible to something like switching between 
private ip's and public ip's. Since clients that come in with a private 
IP usually are accompanied with a sensible hostname from the 
DHCP/internal dns. Public ip addresses get there reverse name from the 
provider and are quite often also NAT-ed, hence these names can't be 
relied upon for proper identification of the source-address. Unless you 
can tell me who e.g. static.kpn.nl was (hint, it was my own connection 
and the source wasn't 213.75.8.38).
Or we could add a (-s?-i?) switch to let the admin decide if he wants to 
switch to Ip-based Source notation.
Just giving my two cents. As I said before, I'll be just as happy to 
keep this file patched for myself.




Re: ftpd log address format

2013-05-07 Thread Ted Unangst
On Sun, May 05, 2013 at 15:18, Stuart Henderson wrote:

 I don't feel too strongly about it but my preference would be to
 log both. There are circumstances (e.g. dhcp with dynamic dns updates)
 where it's useful to have the reverse at the time of connection.

Are you talking about internal or external networks? If it's your
network you should be able to figure it out, and if it's the internet,
I don't know of any ISPs that give you control over dynamic reverse
lookups.

I don't like logging both because there's a not unreasonable chance
the reverse name will be a complete lie, which will just mislead you.



Re: ftpd log address format

2013-05-07 Thread Peter Hessler
On 2013 May 07 (Tue) at 14:26:07 -0400 (-0400), Ted Unangst wrote:
:On Sun, May 05, 2013 at 15:18, Stuart Henderson wrote:
:
: I don't feel too strongly about it but my preference would be to
: log both. There are circumstances (e.g. dhcp with dynamic dns updates)
: where it's useful to have the reverse at the time of connection.
:

I feel somewhat strongly, that it should be IP addresses only.  Should
we log both in apache/nginx?


:Are you talking about internal or external networks? If it's your
:network you should be able to figure it out, and if it's the internet,
:I don't know of any ISPs that give you control over dynamic reverse
:lookups.
:
:I don't like logging both because there's a not unreasonable chance
:the reverse name will be a complete lie, which will just mislead you.
:

I recently saw an IP address that reversed record was 'localhost.'

-- 
The number of arguments is unimportant unless some of them are
correct.
-- Ralph Hartley



Re: ftpd log address format

2013-05-07 Thread Stuart Henderson
On 2013/05/07 14:26, Ted Unangst wrote:
 On Sun, May 05, 2013 at 15:18, Stuart Henderson wrote:
 
  I don't feel too strongly about it but my preference would be to
  log both. There are circumstances (e.g. dhcp with dynamic dns updates)
  where it's useful to have the reverse at the time of connection.
 
 Are you talking about internal or external networks? If it's your
 network you should be able to figure it out, and if it's the internet,

Either..

 I don't know of any ISPs that give you control over dynamic reverse
 lookups.

Funny - apart from mobile networks, I don't think I've ever used
an ISP that *doesn't* let me do that. (There are plenty I could use
which wouldn't let me do that too of course, but they also suck in
other ways).

 I don't like logging both because there's a not unreasonable chance
 the reverse name will be a complete lie, which will just mislead you.

Oh, it doesn't do a forward check of the name it got from reverse
lookup? Yes that's bad.



Re: ftpd log address format

2013-05-07 Thread Ted Unangst
On Tue, May 07, 2013 at 20:54, Stuart Henderson wrote:

 I don't like logging both because there's a not unreasonable chance
 the reverse name will be a complete lie, which will just mislead you.
 
 Oh, it doesn't do a forward check of the name it got from reverse
 lookup? Yes that's bad.

Well, it kind of does. It does a reverse lookup to get a hostname.
Then it does a forward lookup for that hostname and logs that IP. doh.

Forward lookup? Yes. Forward *check*? No.



Re: ftpd log address format

2013-05-07 Thread Stuart Henderson
On 2013/05/07 16:09, Ted Unangst wrote:
 On Tue, May 07, 2013 at 20:54, Stuart Henderson wrote:
 
  I don't like logging both because there's a not unreasonable chance
  the reverse name will be a complete lie, which will just mislead you.
  
  Oh, it doesn't do a forward check of the name it got from reverse
  lookup? Yes that's bad.
 
 Well, it kind of does. It does a reverse lookup to get a hostname.
 Then it does a forward lookup for that hostname and logs that IP. doh.
 
 Forward lookup? Yes. Forward *check*? No.

Wow.

*stab stab stab*



Re: ftpd log address format

2013-05-07 Thread Ted Unangst
On Tue, May 07, 2013 at 21:15, Stuart Henderson wrote:
 On 2013/05/07 16:09, Ted Unangst wrote:
 On Tue, May 07, 2013 at 20:54, Stuart Henderson wrote:

  I don't like logging both because there's a not unreasonable chance
  the reverse name will be a complete lie, which will just mislead you.
 
  Oh, it doesn't do a forward check of the name it got from reverse
  lookup? Yes that's bad.

 Well, it kind of does. It does a reverse lookup to get a hostname.
 Then it does a forward lookup for that hostname and logs that IP. doh.

 Forward lookup? Yes. Forward *check*? No.
 
 Wow.
 
 *stab stab stab*

oh, no, sorry, my mistake. I entirely misread the second getnameinfo
call (thought it was reading from hbuf...). It does something sensible
and does numeric lookup on the socket address.

Still doesn't check that the reversed hostname is sensible, which is
the issue here.



Re: ftpd log address format

2013-05-07 Thread Nick Holland

On 05/07/2013 04:15 PM, Stuart Henderson wrote:

On 2013/05/07 16:09, Ted Unangst wrote:

On Tue, May 07, 2013 at 20:54, Stuart Henderson wrote:


I don't like logging both because there's a not unreasonable chance
the reverse name will be a complete lie, which will just mislead you.


Oh, it doesn't do a forward check of the name it got from reverse
lookup? Yes that's bad.


Well, it kind of does. It does a reverse lookup to get a hostname.
Then it does a forward lookup for that hostname and logs that IP. doh.

Forward lookup? Yes. Forward *check*? No.


Wow.

*stab stab stab*



lesson: dns can lie.
maybe more accurate: reverse dns is sometimes correct.
There is no promise that forward and reverse DNS provide the same info.

Forward and reverse DNS are like the ski resort, where girls are looking 
for husbands and husbands are looking for girls, but the situation is 
not quite as symmetrical as you might think or hope.
(ok, that's a overly stretched analogy, but I've been wanting to use it 
for a long time!)


log the IP, only the IP, nothing but the IP.
Anything you do with DNS from there is you fooling yourself, and 
hopefully you understand what it means.


Nick.



Re: ftpd log address format

2013-05-07 Thread Bob Beck
My two cents on this is that it should be possible (or the default) to
have it logging the IP address.

Having said that ted, yes, DNS is not reliable in some sense - on
the other hand the reverse lookup *is* information that can be useful,
and in the case of dynamic DNS it may contain information that you do
not get after the fact. Saying that if we put it in the log people
will rely on it when it's potentially unreliable is crap. Anyone past
the age of puburty on the internet knows full well that reverse dns is
not necessarily reliable - OTOH sometimes it *is* useful information -
to be treated with a grain of salt.  We should not *prevent* it from
being collected because it is not useful in all situations.