* Network Security Manager merge time?
@ 2014-11-19 16:22 Lars Magne Ingebrigtsen
2014-11-19 16:40 ` Ted Zlatanov
2014-11-19 17:28 ` Robert Pluim
0 siblings, 2 replies; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 16:22 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 16:22 Network Security Manager merge time? Lars Magne Ingebrigtsen
@ 2014-11-19 16:40 ` Ted Zlatanov
2014-11-19 16:53 ` Lars Magne Ingebrigtsen
2014-11-19 18:22 ` Network Security Manager merge time? Lars Magne Ingebrigtsen
2014-11-19 17:28 ` Robert Pluim
1 sibling, 2 replies; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-19 16:40 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 16:40 ` Ted Zlatanov
@ 2014-11-19 16:53 ` Lars Magne Ingebrigtsen
2014-11-19 17:30 ` Ted Zlatanov
2014-11-19 18:22 ` Network Security Manager merge time? Lars Magne Ingebrigtsen
1 sibling, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 16:53 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 16:53 ` Lars Magne Ingebrigtsen
@ 2014-11-19 17:30 ` Ted Zlatanov
2014-11-19 17:59 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-19 17:30 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 17:30 ` Ted Zlatanov
@ 2014-11-19 17:59 ` Lars Magne Ingebrigtsen
2014-11-19 18:34 ` Ted Zlatanov
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 17:59 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 17:59 ` Lars Magne Ingebrigtsen
@ 2014-11-19 18:34 ` Ted Zlatanov
2014-11-19 20:00 ` Ivan Shmakov
2014-11-19 21:41 ` Ted Zlatanov
0 siblings, 2 replies; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-19 18:34 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 18:34 ` Ted Zlatanov
@ 2014-11-19 20:00 ` Ivan Shmakov
2014-11-19 20:25 ` Ted Zlatanov
2014-11-19 21:41 ` Ted Zlatanov
1 sibling, 1 reply; 41+ messages in thread
From: Ivan Shmakov @ 2014-11-19 20:00 UTC (permalink / raw)
To: emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 20:00 ` Ivan Shmakov
@ 2014-11-19 20:25 ` Ted Zlatanov
0 siblings, 0 replies; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-19 20:25 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 18:34 ` Ted Zlatanov
2014-11-19 20:00 ` Ivan Shmakov
@ 2014-11-19 21:41 ` Ted Zlatanov
2014-11-21 11:29 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-19 21:41 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 21:41 ` Ted Zlatanov
@ 2014-11-21 11:29 ` Lars Magne Ingebrigtsen
2014-11-25 14:20 ` Ted Zlatanov
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-21 11:29 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-21 11:29 ` Lars Magne Ingebrigtsen
@ 2014-11-25 14:20 ` Ted Zlatanov
2014-11-25 16:30 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-25 14:20 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-25 14:20 ` Ted Zlatanov
@ 2014-11-25 16:30 ` Lars Magne Ingebrigtsen
2014-11-25 16:46 ` Ted Zlatanov
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-25 16:30 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-25 16:30 ` Lars Magne Ingebrigtsen
@ 2014-11-25 16:46 ` Ted Zlatanov
2014-11-25 17:08 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Ted Zlatanov @ 2014-11-25 16:46 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-25 16:46 ` Ted Zlatanov
@ 2014-11-25 17:08 ` Lars Magne Ingebrigtsen
2014-11-25 18:20 ` intrusive changes Ivan Shmakov
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-25 17:08 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* intrusive changes
2014-11-25 17:08 ` Lars Magne Ingebrigtsen
@ 2014-11-25 18:20 ` Ivan Shmakov
2014-11-30 13:51 ` Stefan Monnier
0 siblings, 1 reply; 41+ messages in thread
From: Ivan Shmakov @ 2014-11-25 18:20 UTC (permalink / raw)
To: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: intrusive changes
2014-11-25 18:20 ` intrusive changes Ivan Shmakov
@ 2014-11-30 13:51 ` Stefan Monnier
2014-11-30 15:12 ` Ivan Shmakov
0 siblings, 1 reply; 41+ messages in thread
From: Stefan Monnier @ 2014-11-30 13:51 UTC (permalink / raw)
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: intrusive changes
2014-11-30 13:51 ` Stefan Monnier
@ 2014-11-30 15:12 ` Ivan Shmakov
2014-11-30 18:07 ` Stefan Monnier
0 siblings, 1 reply; 41+ messages in thread
From: Ivan Shmakov @ 2014-11-30 15:12 UTC (permalink / raw)
To: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 16:40 ` Ted Zlatanov
2014-11-19 16:53 ` Lars Magne Ingebrigtsen
@ 2014-11-19 18:22 ` Lars Magne Ingebrigtsen
2014-11-19 20:46 ` Eli Zaretskii
1 sibling, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 18:22 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 18:22 ` Network Security Manager merge time? Lars Magne Ingebrigtsen
@ 2014-11-19 20:46 ` Eli Zaretskii
2014-11-19 20:54 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2014-11-19 20:46 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 20:46 ` Eli Zaretskii
@ 2014-11-19 20:54 ` Lars Magne Ingebrigtsen
2014-11-19 20:58 ` Lars Magne Ingebrigtsen
2014-11-19 21:18 ` Eli Zaretskii
0 siblings, 2 replies; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 20:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 20:54 ` Lars Magne Ingebrigtsen
@ 2014-11-19 20:58 ` Lars Magne Ingebrigtsen
2014-11-19 21:18 ` Eli Zaretskii
1 sibling, 0 replies; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 20:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 20:54 ` Lars Magne Ingebrigtsen
2014-11-19 20:58 ` Lars Magne Ingebrigtsen
@ 2014-11-19 21:18 ` Eli Zaretskii
2014-11-20 8:42 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2014-11-19 21:18 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 21:18 ` Eli Zaretskii
@ 2014-11-20 8:42 ` Lars Magne Ingebrigtsen
2014-11-20 16:16 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-20 8:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-20 8:42 ` Lars Magne Ingebrigtsen
@ 2014-11-20 16:16 ` Eli Zaretskii
0 siblings, 0 replies; 41+ messages in thread
From: Eli Zaretskii @ 2014-11-20 16:16 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 16:22 Network Security Manager merge time? Lars Magne Ingebrigtsen
2014-11-19 16:40 ` Ted Zlatanov
@ 2014-11-19 17:28 ` Robert Pluim
2014-11-19 17:50 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 41+ messages in thread
From: Robert Pluim @ 2014-11-19 17:28 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 17:28 ` Robert Pluim
@ 2014-11-19 17:50 ` Lars Magne Ingebrigtsen
2014-11-19 19:51 ` Robert Pluim
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 17:50 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 17:50 ` Lars Magne Ingebrigtsen
@ 2014-11-19 19:51 ` Robert Pluim
2014-11-19 19:56 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Robert Pluim @ 2014-11-19 19:51 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 19:51 ` Robert Pluim
@ 2014-11-19 19:56 ` Lars Magne Ingebrigtsen
2014-11-19 20:06 ` Robert Pluim
0 siblings, 1 reply; 41+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 19:56 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Network Security Manager merge time?
2014-11-19 19:56 ` Lars Magne Ingebrigtsen
@ 2014-11-19 20:06 ` Robert Pluim
2014-11-19 20:20 ` Lars Magne Ingebrigtsen
2014-11-20 9:04 ` Robert Pluim
0 siblings, 2 replies; 41+ messages in thread
From: Robert Pluim @ 2014-11-19 20:06 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2014-12-02 13:50 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-19 16:22 Network Security Manager merge time? Lars Magne Ingebrigtsen
2014-11-19 16:40 ` Ted Zlatanov
2014-11-19 16:53 ` Lars Magne Ingebrigtsen
2014-11-19 17:30 ` Ted Zlatanov
2014-11-19 17:59 ` Lars Magne Ingebrigtsen
2014-11-19 18:34 ` Ted Zlatanov
2014-11-19 20:00 ` Ivan Shmakov
2014-11-19 20:25 ` Ted Zlatanov
2014-11-19 21:41 ` Ted Zlatanov
2014-11-21 11:29 ` Lars Magne Ingebrigtsen
2014-11-25 14:20 ` Ted Zlatanov
2014-11-25 16:30 ` Lars Magne Ingebrigtsen
2014-11-25 16:46 ` Ted Zlatanov
2014-11-25 17:08 ` Lars Magne Ingebrigtsen
2014-11-25 18:20 ` intrusive changes Ivan Shmakov
2014-11-30 13:51 ` Stefan Monnier
2014-11-30 15:12 ` Ivan Shmakov
2014-11-30 18:07 ` Stefan Monnier
2014-12-02 10:03 ` Ivan Shmakov
2014-12-02 13:50 ` Stefan Monnier
2014-11-19 18:22 ` Network Security Manager merge time? Lars Magne Ingebrigtsen
2014-11-19 20:46 ` Eli Zaretskii
2014-11-19 20:54 ` Lars Magne Ingebrigtsen
2014-11-19 20:58 ` Lars Magne Ingebrigtsen
2014-11-19 21:18 ` Eli Zaretskii
2014-11-20 8:42 ` Lars Magne Ingebrigtsen
2014-11-20 16:16 ` Eli Zaretskii
2014-11-19 17:28 ` Robert Pluim
2014-11-19 17:50 ` Lars Magne Ingebrigtsen
2014-11-19 19:51 ` Robert Pluim
2014-11-19 19:56 ` Lars Magne Ingebrigtsen
2014-11-19 20:06 ` Robert Pluim
2014-11-19 20:20 ` Lars Magne Ingebrigtsen
2014-11-19 20:25 ` Lars Magne Ingebrigtsen
2014-11-19 20:26 ` Robert Pluim
2014-11-19 20:32 ` Lars Magne Ingebrigtsen
2014-11-20 8:00 ` Robert Pluim
2014-11-20 8:43 ` Lars Magne Ingebrigtsen
2014-11-20 9:04 ` Robert Pluim
2014-11-20 10:39 ` Lars Magne Ingebrigtsen
2014-11-20 11:34 ` Robert Pluim
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.