Network Security Manager merge time?

Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

I think the NSM is basically feature complete (i.e., it does what it's
supposed to according to our discussions).  Bugs probably exist, as in
all code.

So perhaps it's time to merge it with trunk?  `nsm-security-level' would
be set to `low', which means that it basically would do nothing.

But we would get more testing of the basic parts -- that I haven't
screwed up Emacs too much.  And then, after a week or so, we could
switch it to `medium', which would activate it, and then we'll see what
people think about the way it works.

Does this sound like a plan?

And it would be nice if somebody more wise in the way of doing large git
merges could do it.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Wed, 19 Nov 2014 17:22:05 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I think the NSM is basically feature complete (i.e., it does what it's
LMI> supposed to according to our discussions).  Bugs probably exist, as in
LMI> all code.

LMI> So perhaps it's time to merge it with trunk?  `nsm-security-level' would
LMI> be set to `low', which means that it basically would do nothing.

LMI> But we would get more testing of the basic parts -- that I haven't
LMI> screwed up Emacs too much.  And then, after a week or so, we could
LMI> switch it to `medium', which would activate it, and then we'll see what
LMI> people think about the way it works.

Does it deprecate `gnutls-verify-error'?  If so, we should note that.

Ted

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Does it deprecate `gnutls-verify-error'?  If so, we should note that.

No, all the boot-time checks are still in there, so if the user wants to
use the gnutls built-in checking stuff instead of the NSM for some
reason or other, that's still possible.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think the NSM is basically feature complete (i.e., it does what it's
> supposed to according to our discussions).  Bugs probably exist, as in
> all code.
>
> So perhaps it's time to merge it with trunk?  `nsm-security-level' would
> be set to `low', which means that it basically would do nothing.
>
> But we would get more testing of the basic parts -- that I haven't
> screwed up Emacs too much.  And then, after a week or so, we could
> switch it to `medium', which would activate it, and then we'll see what
> people think about the way it works.

I've just tried it in 'paranoid' mode, and whilst gnus can connect to
gmane, (modulo the warnings about a self-signed certificate), my other
nntp server news.eternal-september.org is getting denied. Which bits of
.gnus etc would you like?

Robert

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Wed, 19 Nov 2014 17:53:07 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Does it deprecate `gnutls-verify-error'?  If so, we should note that.

LMI> No, all the boot-time checks are still in there, so if the user wants to
LMI> use the gnutls built-in checking stuff instead of the NSM for some
LMI> reason or other, that's still possible.

I'd rather deprecate it in favor of `nsm-security-level', especially if
you're OK with the ability to set the level per host or subnet, and per
service. The `gnutls-verify-error' checks are all 'medium I think.

(And I'd name or alias that NSM variable to `network-security-level'
because "nsm" means nothing to a new user, assuming NSM will be loaded
by default.)

(Oh, and I'd make `nsm-save-host-names' t by default, because your
worries about information leakage are in the 'high or above security
level IMO :)

Parenthetically
Ted

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I've just tried it in 'paranoid' mode, and whilst gnus can connect to
> gmane, (modulo the warnings about a self-signed certificate), my other
> nntp server news.eternal-september.org is getting denied. Which bits of
> .gnus etc would you like?

I'm reading from news.eternal-september.org, too, but I think I'm not
using TLS there?

What's your setting for that server?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'd rather deprecate it in favor of `nsm-security-level', especially if
> you're OK with the ability to set the level per host or subnet, and per
> service. The `gnutls-verify-error' checks are all 'medium I think.

I can imagine that some people would rather leave all this up to
gnutls...

> (And I'd name or alias that NSM variable to `network-security-level'
> because "nsm" means nothing to a new user, assuming NSM will be loaded
> by default.)

Yes.

> (Oh, and I'd make `nsm-save-host-names' t by default, because your
> worries about information leakage are in the 'high or above security
> level IMO :)

Heh.  But ssh has the same paranoid defaults, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

By the way, could someone with Windows try to see whether the "nsm"
branch compiles?  I tried my best to cargo cult the Windows library
interface bits based on how it's done for the other gnutls functions,
but the likelihood of me not getting any of that wrong is about zero.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Wed, 19 Nov 2014 18:59:16 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I'd rather deprecate it in favor of `nsm-security-level', especially if
>> you're OK with the ability to set the level per host or subnet, and per
>> service. The `gnutls-verify-error' checks are all 'medium I think.

LMI> I can imagine that some people would rather leave all this up to
LMI> gnutls...

As far as user-level customization, I'd rather not have multiple
variables.  The checks will be done the same way, just based on
`network-security-level' instead of specific checkboxes like now.

>> (And I'd name or alias that NSM variable to `network-security-level'
>> because "nsm" means nothing to a new user, assuming NSM will be loaded
>> by default.)

LMI> Yes.

Cool!

>> (Oh, and I'd make `nsm-save-host-names' t by default, because your
>> worries about information leakage are in the 'high or above security
>> level IMO :)

LMI> Heh.  But ssh has the same paranoid defaults, I think.

I was going to say it doesn't for me on Ubuntu, but apparently in the
last N months+years the default has changed quietly. So now I have no
idea how many of my known_hosts are for virtual machines or other
disposable SSH servers. Grrrrrrreat.  Ah, here's why, from the
ssh_config man page:

     Note that the Debian openssh-client package sets several options as standard in /etc/ssh/ssh_config which are not the default in ssh(1):
...
           ·   HashKnownHosts yes
           ·   GSSAPIAuthentication yes

I'll be disabling that one...

Ted

Re: Network Security Manager merge time?

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I've just tried it in 'paranoid' mode, and whilst gnus can connect to
>> gmane, (modulo the warnings about a self-signed certificate), my other
>> nntp server news.eternal-september.org is getting denied. Which bits of
>> .gnus etc would you like?
>
> I'm reading from news.eternal-september.org, too, but I think I'm not
> using TLS there?
>
> What's your setting for that server?

I don't think I'm using TLS either:

 gnus-secondary-select-methods
 '(
   (nntp "eternal"
	 (nntp-address "news.eternal-september.org")))

and my .authinfo entry specifies only nntp. If I set nsm-security-level
to 'low it all works.

Robert

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I don't think I'm using TLS either:
>
>  gnus-secondary-select-methods
>  '(
>    (nntp "eternal"
> 	 (nntp-address "news.eternal-september.org")))
>
> and my .authinfo entry specifies only nntp.

It will upgrade via STARTTLS to encrypted automatically.

> If I set nsm-security-level to 'low it all works.

Hm.  What does

(gnutls-peer-status 
  (open-network-stream
   "nntpd" (get-buffer-create "*nntp*") "news.eternal-september.org" "nntp"
   :end-of-command "^\\([2345]\\|[.]\\).*\n"
   :capability-command "HELP\r\n"
   :success "^3"
   :starttls-function
   (lambda (capabilities)
     (if (not (string-match "STARTTLS" capabilities))
         nil
       "STARTTLS\r\n"))))

evaluate to for you?  (On different security levels.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Ivan Shmakov]

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Wed, 19 Nov 2014 18:59:16 +0100 Lars Magne Ingebrigtsen wrote:
>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

 TZ> I'd rather deprecate it in favor of `nsm-security-level',
 TZ> especially if you're OK with the ability to set the level per host
 TZ> or subnet, and per service.  The `gnutls-verify-error' checks are
 TZ> all 'medium I think.

 LMI> I can imagine that some people would rather leave all this up to
 LMI> gnutls...

 TZ> As far as user-level customization, I'd rather not have multiple
 TZ> variables.  The checks will be done the same way, just based on
 TZ> `network-security-level' instead of specific checkboxes like now.

	I have gnutls-verify-error set in my ~/.emacs.  After I upgrade
	to an NSM-enabled Emacs, how exactly will it get mapped to the
	NSM settings?

[…]

 TZ> I was going to say it doesn't for me on Ubuntu, but apparently in
 TZ> the last N months+years the default has changed quietly.  So now I
 TZ> have no idea how many of my known_hosts are for virtual machines or
 TZ> other disposable SSH servers.  Grrrrrrreat.  Ah, here's why, from
 TZ> the ssh_config man page:

 TZ> Note that the Debian openssh-client package sets several options as
 TZ> standard in /etc/ssh/ssh_config which are not the default in
 TZ> ssh(1): ...  · HashKnownHosts yes · GSSAPIAuthentication yes

	I’m pretty sure that this setting was there for years.  Why, the
	earliest hashed ~/.ssh/known_hosts entries I’m able to find in
	my backups right now date back to March, 2008.

 TZ> I'll be disabling that one...

	FWIW, I tend to have reservations when it comes to software
	editing my configuration files on their own.  Thus, I’ve ended
	up making known_hosts read-only, and adding ssh-keyscan(1) data
	to it manually as necessary.

-- 
FSF associate member #7257  np. Coming Home — Iron Maiden   … B6A0 230E 334A

Re: Network Security Manager merge time?

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I don't think I'm using TLS either:
>>
>>  gnus-secondary-select-methods
>>  '(
>>    (nntp "eternal"
>> 	 (nntp-address "news.eternal-september.org")))
>>
>> and my .authinfo entry specifies only nntp.
>
> It will upgrade via STARTTLS to encrypted automatically.
>
>> If I set nsm-security-level to 'low it all works.
>
> Hm.  What does
>
> (gnutls-peer-status 
>   (open-network-stream
>    "nntpd" (get-buffer-create "*nntp*") "news.eternal-september.org" "nntp"
>    :end-of-command "^\\([2345]\\|[.]\\).*\n"
>    :capability-command "HELP\r\n"
>    :success "^3"
>    :starttls-function
>    (lambda (capabilities)
>      (if (not (string-match "STARTTLS" capabilities))
>          nil
>        "STARTTLS\r\n"))))
>
> evaluate to for you?  (On different security levels.)

With low:

(:warnings ((:self-signed "certificate signer was not found (self-signed)") (:invalid "certificate could not be verified")) :certificate (:version 3 :serial-number "0f:79:de" :issuer "O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org" :valid-from "2014-08-31" :valid-to "2015-02-27" :subject "CN=news.eternal-september.org" ...))

With paranoid:

Debugger entered--Lisp error: (wrong-type-argument processp nil)
  gnutls-peer-status(nil)
  eval((gnutls-peer-status (open-network-stream "nntpd" (get-buffer-create "*nntp*") "news.eternal-september.org" "nntp" :end-of-command "^\\([2345]\\|[.]\\).*\n" :capability-command "HELP\n" :success "^3" :starttls-function (function (lambda (capabilities) (if (not (string-match "STARTTLS" capabilities)) nil "STARTTLS\n"))))) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

and *nntp* contains

200 mx02.eternal-september.org InterNetNews NNRP server INN 2.6.0 (20141110 snapshot) ready (posting ok)
100 Legal commands
  ARTICLE [message-ID|number]
  AUTHINFO USER name|PASS password|SASL mechanism [initial-response]|GENERIC program [argument ...]
  BODY [message-ID|number]
  CAPABILITIES [keyword]
  DATE
  GROUP newsgroup
  HDR header [message-ID|range]
  HEAD [message-ID|number]
  HELP
  IHAVE message-ID
  LAST
  LIST [ACTIVE [wildmat]|ACTIVE.TIMES [wildmat]|COUNTS [wildmat]|DISTRIB.PATS|DISTRIBUTIONS|HEADERS [MSGID|RANGE]|MODERATORS|MOTD|NEWSGROUPS [wildmat]|OVERVIEW.FMT|SUBSCRIPTIONS [wildmat]]
  LISTGROUP [newsgroup [range]]
  MODE READER
  NEWGROUPS [yy]yymmdd hhmmss [GMT]
  NEWNEWS wildmat [yy]yymmdd hhmmss [GMT]
  NEXT
  OVER [range]
  POST
  QUIT
  STARTTLS
  STAT [message-ID|number]
  XGTITLE [wildmat]
  XHDR header [message-ID|range]
  XOVER [range]
  XPAT header message-ID|range pattern [pattern ...]
Report problems to <usenet@eternal-september.org>.
.
382 Begin TLS negotiation now
100 Legal commands
  ARTICLE [message-ID|number]
  AUTHINFO USER name|PASS password|SASL mechanism [initial-response]|GENERIC program [argument ...]
  BODY [message-ID|number]
  CAPABILITIES [keyword]
  DATE
  GROUP newsgroup
  HDR header [message-ID|range]
  HEAD [message-ID|number]
  HELP
  IHAVE message-ID
  LAST
  LIST [ACTIVE [wildmat]|ACTIVE.TIMES [wildmat]|COUNTS [wildmat]|DISTRIB.PATS|DISTRIBUTIONS|HEADERS [MSGID|RANGE]|MODERATORS|MOTD|NEWSGROUPS [wildmat]|OVERVIEW.FMT|SUBSCRIPTIONS [wildmat]]
  LISTGROUP [newsgroup [range]]
  MODE READER
  NEWGROUPS [yy]yymmdd hhmmss [GMT]
  NEWNEWS wildmat [yy]yymmdd hhmmss [GMT]
  NEXT
  OVER [range]
  POST
  QUIT
  STARTTLS
  STAT [message-ID|number]
  XGTITLE [wildmat]
  XHDR header [message-ID|range]
  XOVER [range]
  XPAT header message-ID|range pattern [pattern ...]
Report problems to <usenet@eternal-september.org>.
.

Process nntpd<2> deleted

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> With paranoid:
>
> Debugger entered--Lisp error: (wrong-type-argument processp nil)
>   gnutls-peer-status(nil)
>   eval((gnutls-peer-status (open-network-stream "nntpd"

Ah, thanks.  I managed to reproduce this now.  If the peer fingerprint
changes, and you have the `paranoid' setting, it refuses the connection
silently.

I'll push a fix in a few minutes more testing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Wed, 19 Nov 2014 20:00:36 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

IS> 	I have gnutls-verify-error set in my ~/.emacs.  After I upgrade
IS> 	to an NSM-enabled Emacs, how exactly will it get mapped to the
IS> 	NSM settings?

I'd guess you'll be able to just copy it over with some small change,
but I think deprecating GnuTLS-specific checks for 25.x is reasonable.
I will not just cut it off.

(It looks like we'll have the NSM only in master, not emacs-24).

TZ> ssh(1): ...  · HashKnownHosts yes · GSSAPIAuthentication yes

IS> 	I’m pretty sure that this setting was there for years.  Why, the
IS> 	earliest hashed ~/.ssh/known_hosts entries I’m able to find in
IS> 	my backups right now date back to March, 2008.

I guess it finally made it to my Ubuntu system :)

Ted

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'll push a fix in a few minutes more testing.

Should be OK now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> With paranoid:
>>
>> Debugger entered--Lisp error: (wrong-type-argument processp nil)
>>   gnutls-peer-status(nil)
>>   eval((gnutls-peer-status (open-network-stream "nntpd"
>
> Ah, thanks.  I managed to reproduce this now.  If the peer fingerprint
> changes, and you have the `paranoid' setting, it refuses the connection
> silently.
>

How can the peer fingerprint have changed? I've never successfully
connected to this server using paranoid, and no fingerprint was written
to network-security.data

> I'll push a fix in a few minutes more testing.

I'll stick 'git pull' in cron :)

Robert

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> How can the peer fingerprint have changed? I've never successfully
> connected to this server using paranoid, and no fingerprint was written
> to network-security.data

I changed how the fingerprint was made.  :-)  It used to be a
certificate hash, but it's now a public key hash.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 19 Nov 2014 19:22:13 +0100
> 
> By the way, could someone with Windows try to see whether the "nsm"
> branch compiles?

It won't: you are calling the GnuTLS functions directly, instead of
through the fn_* macros.

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It won't: you are calling the GnuTLS functions directly, instead of
> through the fn_* macros.

I can't see any such calls on the branch, but perhaps my grep-fu isn't
looking for the right thing.  Which calls in particular?

(And have you updated the branch?  The cargo culting happened in a
commit earlier today.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I can't see any such calls on the branch, but perhaps my grep-fu isn't
> looking for the right thing.  Which calls in particular?

Found two more.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 19 Nov 2014 21:54:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It won't: you are calling the GnuTLS functions directly, instead of
> > through the fn_* macros.
> 
> I can't see any such calls on the branch, but perhaps my grep-fu isn't
> looking for the right thing.  Which calls in particular?

  gnutls_x509_crt_get_serial
  gnutls_x509_crt_get_issuer_dn
  gnutls_x509_crt_get_activation_time
  gnutls_x509_crt_get_pk_algorithm
  gnutls_pk_algorithm_get_name
  gnutls_sec_param_get_name
  gnutls_x509_crt_get_issuer_unique_id
  gnutls_x509_crt_get_subject_unique_id
  gnutls_x509_crt_get_signature_algorithm
  gnutls_sign_algorithm_get_name
  gnutls_x509_crt_get_key_id

> (And have you updated the branch?  The cargo culting happened in a
> commit earlier today.)

I said "git diff ...origin/nsm", I hope that's the right command to
see the diffs against the trunk.

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Wed, 19 Nov 2014 13:34:53 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 19 Nov 2014 18:59:16 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I'd rather deprecate it in favor of `nsm-security-level', especially if
>>> you're OK with the ability to set the level per host or subnet, and per
>>> service. The `gnutls-verify-error' checks are all 'medium I think.

LMI> I can imagine that some people would rather leave all this up to
LMI> gnutls...

TZ> As far as user-level customization, I'd rather not have multiple
TZ> variables.  The checks will be done the same way, just based on
TZ> `network-security-level' instead of specific checkboxes like now.

Looking at the code, there's a lot of copy+pasta there between the
GnuTLS verification in `gnutls-boot' and the message collection in
`gnutls-peer-status'. Could you factor that out so there's only one
sequence of checks to maintain, especially since I'd like to deprecate
the GnuTLS verification in favor of NSM? Basically call
`gnutls-peer-status' in `gnutls-boot' and then iterate through the
messages (which can be the simpler version you use instead of the one
with the hostname attached I have in `gnutls-boot'). I can do it if you
prefer.

Ted

Re: Network Security Manager merge time?

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> How can the peer fingerprint have changed? I've never successfully
>> connected to this server using paranoid, and no fingerprint was written
>> to network-security.data
>
> I changed how the fingerprint was made.  :-)  It used to be a
> certificate hash, but it's now a public key hash.

OK, works for me now as of 71a78bd. Looks like it was a deep bugfix ;)

Robert

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I can't see any such calls on the branch, but perhaps my grep-fu isn't
>> looking for the right thing.  Which calls in particular?

[...]

>   gnutls_x509_crt_get_issuer_unique_id

The call for that is, for instance:

    err = fn_gnutls_x509_crt_get_issuer_unique_id (cert, NULL, &buf_size);
    if (err == GNUTLS_E_SHORT_MEMORY_BUFFER) {
      char *buf = malloc (buf_size);
      err = fn_gnutls_x509_crt_get_issuer_unique_id (cert, buf, &buf_size);

(And the same with the other functions in the list.)

>> (And have you updated the branch?  The cargo culting happened in a
>> commit earlier today.)
>
> I said "git diff ...origin/nsm", I hope that's the right command to
> see the diffs against the trunk.

Perhaps a "git pull" is missing?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>> I changed how the fingerprint was made.  :-)  It used to be a
>> certificate hash, but it's now a public key hash.
>
> OK, works for me now as of 71a78bd. Looks like it was a deep bugfix ;)

:-)  Yeah, a `C-t'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Robert Pluim]

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> It will upgrade via STARTTLS to encrypted automatically.

This is true. Given the news about various ISPs removing 'STARTTLS' from
server capabilities, I've now moved over to using nntps directly. Whilst
that is easy to set up (once you read the manual :-) ) I do wonder if it
would be helpful to inform users that using nntps might be an option
when their connection is upgraded? Perhaps even offer to switch their
connection method to nntp-open-tls-stream for them?

Robert

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> This is true. Given the news about various ISPs removing 'STARTTLS' from
> server capabilities, I've now moved over to using nntps directly.

I doubt ISPs have even heard about NNTP these days.  :-)  And NSM will
warn you if a previously STARTTL server now is lacking encryption.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> This is true. Given the news about various ISPs removing 'STARTTLS' from
>> server capabilities, I've now moved over to using nntps directly.
>
> I doubt ISPs have even heard about NNTP these days.  :-)  And NSM will
> warn you if a previously STARTTL server now is lacking encryption.

They were doing it for smtp connections as well. Anyway, the warning is
a good thing to know.

Thanks

Robert

Re: Network Security Manager merge time?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 20 Nov 2014 09:42:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I can't see any such calls on the branch, but perhaps my grep-fu isn't
> >> looking for the right thing.  Which calls in particular?
> 
> [...]
> 
> >   gnutls_x509_crt_get_issuer_unique_id
> 
> The call for that is, for instance:
> 
>     err = fn_gnutls_x509_crt_get_issuer_unique_id (cert, NULL, &buf_size);
>     if (err == GNUTLS_E_SHORT_MEMORY_BUFFER) {
>       char *buf = malloc (buf_size);
>       err = fn_gnutls_x509_crt_get_issuer_unique_id (cert, buf, &buf_size);
> 
> (And the same with the other functions in the list.)

Obviously, that's not what I saw.  I copy/pasted the functions from
the diffs.

> >> (And have you updated the branch?  The cargo culting happened in a
> >> commit earlier today.)
> >
> > I said "git diff ...origin/nsm", I hope that's the right command to
> > see the diffs against the trunk.
> 
> Perhaps a "git pull" is missing?

No, I did the diff immediately after pulling.

However, it takes time to review the diffs, and if you kept committing
changes during that time, and never said "forget what you saw until
now 'cause I changed all of it", then I couldn't possibly know I'm
staring at stale code.

Anyway, it looks fine now that I repeat the procedure.

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Looking at the code, there's a lot of copy+pasta there between the
> GnuTLS verification in `gnutls-boot' and the message collection in
> `gnutls-peer-status'. Could you factor that out so there's only one
> sequence of checks to maintain, especially since I'd like to deprecate
> the GnuTLS verification in favor of NSM? Basically call
> `gnutls-peer-status' in `gnutls-boot' and then iterate through the
> messages (which can be the simpler version you use instead of the one
> with the hostname attached I have in `gnutls-boot'). I can do it if you
> prefer.

Sure; go ahead.  The verification checks should probably be factored out
from `gnutls-peer-status', though, since `gnutls-boot' doesn't need the
other things it calculates (like the fingerprints etc).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Fri, 21 Nov 2014 12:29:45 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Looking at the code, there's a lot of copy+pasta there between the
>> GnuTLS verification in `gnutls-boot' and the message collection in
>> `gnutls-peer-status'. Could you factor that out so there's only one
>> sequence of checks to maintain, especially since I'd like to deprecate
>> the GnuTLS verification in favor of NSM? Basically call
>> `gnutls-peer-status' in `gnutls-boot' and then iterate through the
>> messages (which can be the simpler version you use instead of the one
>> with the hostname attached I have in `gnutls-boot'). I can do it if you
>> prefer.

LMI> Sure; go ahead.  The verification checks should probably be factored out
LMI> from `gnutls-peer-status', though, since `gnutls-boot' doesn't need the
LMI> other things it calculates (like the fingerprints etc).

OK, done as follows:

* `gnutls-peer-status' returns a simple list of symbols, which can then
  be passed to `gnutls-peer-status-warning-describe' for the full
  string. That could turn into a more complex struct or symbol
  properties, but for now it's just a string message. I adapted
  `gnutls-boot' accordingly. The certificate info is not generated when
  it's called through `gnutls-boot' because that struct is not populated
  yet, so there's no wasted cycles.

* nsm.el was also adapted accordingly.

I think we should now do the following:

* deprecate `gnutls-verify-error' in favor of `network-security-level'

* to help the migration, map :trustfiles and :hostname to 'medium (IIUC)

* add the ability to set the `network-security-level' per hostname regex

* put the 'gnutls customization group next to 'nsm under 'comm

WDYT?

Ted

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think we should now do the following:
>
> * deprecate `gnutls-verify-error' in favor of `network-security-level'
>
> * to help the migration, map :trustfiles and :hostname to 'medium (IIUC)

I think that proper Professional Security Professionals won't trust that
us lowly Emacs developers can get something as sacred as this stuff
right, so they will still want to be able to instruct the gnutls library
to refuse connections directly.

And I see no great reason why we can't do that.  I mean, the code is
already there.  The only downside is that we could get rid of some code,
and there would only be one thing for users to consider customising
instead of two, so it would allow us to get rid of that potential
confusion.

But I have no strong opinions on this.  Anybody?

> * add the ability to set the `network-security-level' per hostname regex

I still don't see the use case.  :-) The only reason to bump the level
over `medium' is that the user is worried that the NSA is paying a rogue
CA to issue certificates for your bank, and if you are, you should be
running on `high' always.

And `medium' is so unintrusive that I hope that nobody will feel the
need to run with `low'.  If they feel that need, then we've misdesigned
something.

> * put the 'gnutls customization group next to 'nsm under 'comm

Yeah, that would be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Network Security Manager merge time?

[Ted Zlatanov]

On Tue, 25 Nov 2014 17:30:36 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think we should now do the following:
>> 
>> * deprecate `gnutls-verify-error' in favor of `network-security-level'
>> 
>> * to help the migration, map :trustfiles and :hostname to 'medium (IIUC)

LMI> I think that proper Professional Security Professionals won't trust that
LMI> us lowly Emacs developers can get something as sacred as this stuff
LMI> right, so they will still want to be able to instruct the gnutls library
LMI> to refuse connections directly.

But it will!  It will simply look at `network-security-level' instead of
the old variable.

>> * add the ability to set the `network-security-level' per hostname regex

LMI> I still don't see the use case.  :-) The only reason to bump the level
LMI> over `medium' is that the user is worried that the NSA is paying a rogue
LMI> CA to issue certificates for your bank, and if you are, you should be
LMI> running on `high' always.

OK, you may be right.  No need to overengineer it.

LMI> And `medium' is so unintrusive that I hope that nobody will feel the
LMI> need to run with `low'.  If they feel that need, then we've misdesigned
LMI> something.

Such an optimist, you are.

>> * put the 'gnutls customization group next to 'nsm under 'comm

LMI> Yeah, that would be nice.

Moved.

Ted

Re: Network Security Manager merge time?

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> And `medium' is so unintrusive that I hope that nobody will feel the
> LMI> need to run with `low'.  If they feel that need, then we've misdesigned
> LMI> something.
>
> Such an optimist, you are.

Indeed.  :-)

I know that any interface change will have some people just fuming.
Just have a peek at the bug report about the new "You can run the
command..." help thing, and that's really non-intrusive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

intrusive changes

[Ivan Shmakov]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

[…]

 > I know that any interface change will have some people just fuming.
 > Just have a peek at the bug report about the new "You can run the
 > command..." help thing, and that's really non-intrusive.

	Showing that prompt every single time the user does ‘M-x <up>’
	isn’t something I’d call “non-intrusive.”

	Thanks for filing #19013, BTW, – I’m not familiar with that part
	of the code, and I would sure have spent quite some time
	searching for where to disable that feature at without reading
	the discussion that ensued.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: intrusive changes

[Stefan Monnier]

> 	Showing that prompt every single time the user does ‘M-x <up>’
> 	isn’t something I’d call “non-intrusive.”

It's not a prompt, just a message.  That bug has been fixed.  It was
trivial to fix.  Basing a decision on the presence of a bug without even
trying to fix this bug first is not a good idea.


        Stefan

Re: intrusive changes

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

 >> Showing that prompt every single time the user does ‘M-x <up>’ isn’t
 >> something I’d call “non-intrusive.”

 > It's not a prompt, just a message.

	I stand corrected.

 > That bug has been fixed.

	FWIW, that doesn’t change a thing to me, – I still find that
	particular feature not helpful, and keep it disabled.  (Along
	with global-eldoc-mode, transient-mark-mode, the binding of
	[home] to beginning-of-line, and some more.)

 > It was trivial to fix.

	For someone knowledgeable to that part of the code, I presume.

 > Basing a decision on the presence of a bug without even trying to fix
 > this bug first is not a good idea.

	Adding untested features without providing an easy way for the
	user to opt out is not a good idea, either.

PS.  Belated thanks to Dmitry Gutov for dealing with #17008.  Filing a
	bug like that was somewhere near the very bottom of my “to do”
	list for a while.  And now I’m pleasantly surprised to discover
	that the issue was actually fixed over half an year ago.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: intrusive changes

[Stefan Monnier]

> 	Adding untested features without providing an easy way for the
> 	user to opt out is not a good idea, either.

Adding features to master is the way we get them tested in the first place.


        Stefan

Re: intrusive changes

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

 >> Adding untested features without providing an easy way for the user
 >> to opt out is not a good idea, either.

 > Adding features to master is the way we get them tested in the first
 > place.

	That’s the point.  And in this case, testing the feature
	resulted in #19152 being filed.

	Although indeed, providing options to disable new features is
	much more important for releases.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: intrusive changes

[Stefan Monnier]

>> Adding features to master is the way we get them tested in the first
>> place.
> 	That’s the point.  And in this case, testing the feature
> 	resulted in #19152 being filed.

Exactly.  The process worked just as it should, pointing out the need to
add a config var to turn the thing off, as well as pointing out a bug in
the implementation.


        Stefan