Re: breakindent, take 2

2007-05-29 Thread Matthew Winn
On Mon, 28 May 2007 16:04:17 +0200, A.J.Mechelynck

 With this change plus 'linebreak' on, it could be made to simulate French 
 paragrah style for text, where the first line of a paragraph starts maybe 1em 
 or so right of the left margin (but with no blank line, unlike American 
 paragraph style which uses flush-left alignment with a blank line between 

That would be useful.

Would there be any benefit from making it a string option that
accepted numbers only, so there could be three styles?

breakindent=nabsolute positioning or broken lines
breakindent=+n   broken lines have additional indentation
breakindent=-n   broken lines have reduced indentation

Matthew Winn

Re: Vim version 7.1a BETA has been released

2007-05-07 Thread Matthew Winn
On Sun, 06 May 2007 14:46:22 +0200, A.J.Mechelynck

 Michael Henry wrote:
  Gary Johnson wrote:
  On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote:
   (Warning: In the ln command as used here, the target name comes 
  before the  link name. I find this counter-intuitive.)
  It's not just me then.  I have to think carefully about that every 
  time I use ln.
  I used to find this hard to remember until I realized that 'ln' and 'cp' 
  are very similar.  The 'cp' command copies one or more sources to a 
  destination; the 'ln' command links one or more sources to a destination 
  as well.  I tend to think of 'ln -s' as copy using symlinks.  The 
  order and meaning of the arguments is the same between the commands, 
  which I now find consistent and intuitive.
 The problem is, cp -v file1 file2 outputs
   `file1' - `file2'
 (the data has been copied from file1 to file2) but ln -sv file1 file2 
   file2 - file1
 (file2 is now a link pointing to file1). I still have to call up the help 
 the manual every time I invoke it.

Just remember that for all of cp, ln and mv, the existing file comes

I think the confusion arises because people think of ln as create a
link, so they see ln x y as create a link x..., which it isn't.
It makes more sense if you think of it this way:

mv x ymove file x to file y
cp x ycopy file x to file y
ln x ylink file x to file y

Matthew Winn

Re: feedkeys() allowed in sandbox

2007-05-03 Thread Matthew Winn
On Tue, 1 May 2007 19:42:02 +1000, John Beckett

 Matthew Winn wrote:
  If there was a security problem in Vim do you really think it
  couldn't be exploited in 100 characters? That's a pretty shaky
  foundation on which to build your security.
 I am quite surprised at the lack of appreciation for the merits
 of defense in depth here. I am not claiming that a length
 limit would preclude damage, just that a modeline should be
 sanity checked before execution, and a reasonable length would
 be the first check.

What constitutes a reasonable length? Vim has to load the entire
document including its modeline into memory anyway, so there's no
denial-of-service implications in allowing unlimited modelines.
Your suggestion amounts to I won't use a modeline longer than X,
so nobody will use a modeline longer than X.

My objection to your idea is that it won't improve security by even
the tiniest bit. It's not defence in depth at all. It's a worthless
measure that can't achieve anything useful and can only get in the
way of legitimate uses. Any modeline long enough to be useful for a
legitimate purpose must also be long enough to be useful for a hostile

 It's sensational that Vim can process files with very long
 lines, for the occasions we need that. But it would be absurd
 for Vim to process a multi-megabyte modeline.

Where do you draw the line between absurd and reasonable? When I write
options I spell out the names in full so they're easier to understand
for someone who doesn't know Vim well. That means that my modelines
are quite long. But someone who wanted to save space could use the
abbreviated form of an option. That means that if a modeline can be
long enough to satisfy me it would give an attacker the ability to use
several times as many options to craft their exploit as are needed for
general use.

 By all means abuse me for my cheeky suggestion to limit
 modelines to 100 bytes, but while doing that you might agree
 that some limit under 1MB should be enforced.


In some places there are good reasons for limiting sizes. For example,
RFC2822 places a limit of 998 characters on the length of a line. The
reason for this is so that RFC2822-conforming applications don't have
to deal with data of arbitrary length and allocate unlimited buffers
to handle it. They can allocate a buffer 1001 characters long and
discard anything that won't fit in the buffer, thereby preventing the
possibility of denial-of-service attacks from someone sending a line
several hundred megabytes long.

Vim doesn't have that issue because it must load the entire file into
memory anyway. Vim already knows how to deal with long lines, so
there's no extra penalty incurred by a multi-megabyte modeline.

  A web browser should be able to handle anything thrown at it
  in a way that doesn't compromise security. _Every_ application
  should be able to handle anything thrown at it in a way that
  doesn't compromise security.
 Even if a program is perfect now, a later change can introduce a
 bug. Any program which can automatically execute untrusted code
 should sanity-check the input as a separate step from
 sandboxing. That is standard Security 101 stuff - not my idea.

I've been working with computer security for over two decades. I know
about standard security stuff. I also know that security that doesn't
work is worse than no security at all, because it creates an illusion
of protection where none exists.

  Perl and Vim have exactly the same requirements: the need to
  safely handle code taken from an untrustworthy source. It
  makes no difference whether it comes directly from a network
  or from a disk. (If, like me, you use Vim as your source
  viewer for web pages, the need for the same level of security
  is obvious.)
 It doesn't matter, but for the record, Perl's tainting system is
 not related to the scenario you describe. Perl wants to make
 sure that untrusted input is not later used as the basis for
 some expression that could do harm, such as executing SQL code.

That's what I meant, and that's exactly what Vim needs as well. Both
applications read data from a source that can't be trusted, and both
need to ensure that untrusted data can't be used in a situation where
it could be dangerous. In Vim's case it needs to make sure that an
expression used in an option set from a modeline can't be used later
in a way that would cause harm, such as executing a command.

Take a look at the original message. It sets foldmethod to something
that triggers the execution of an external command after the modeline
has been processed. Imagine you have a web page that contains the
following (with the real command removed so it can't cause problems,
just in case someone does view this in Vim; think of rm -rf /):

vim: fdm=expr fde=feedkeys(\\:!dangerous-command-here\\cr)

Now imagine that someone uses Vim as their browser's view source
application. That's _exactly_ the thing Perl's

Re: feedkeys() allowed in sandbox

2007-04-30 Thread Matthew Winn
On Sun, 29 Apr 2007 19:10:55 +1000, John Beckett

 Matthew Winn wrote:
  I don't like the idea of preventing modelines over 100 bytes.
 I imagine (haven't looked) that a modeline has no hard limit to
 its length. So multi-megabyte modelines are probably handled by
 Vim. That's potentially offering attackers extraordinary power.

It doesn't matter how many bytes are accepted. Security that depends
on the assumption that an exploit can't be written in less than an
arbitrarily chosen number of bytes is no security at all. Take a look
at some of the coding golf competitions that take place online, where
the object is to perform some complex task in the minimum number of

If there was a security problem in Vim do you really think it couldn't
be exploited in 100 characters? That's a pretty shaky foundation on
which to build your security.

 Would someone who wants a modeline longer than 100 bytes please
 show us an example. How about a 200-byte limit?

Oh, so nobody will need a long modeline? Just like they will never
need more than [insert your favourite inaccurate prediction about
the maximum amount of computing power anyone would ever need here].

 Modelines are enabled by default, and are very useful for things
 like setting tabs. So most people, and all new installs, will
 have modelines enabled. It's very poor security practice to
 offer a rich auto-execution environment with a single line of
 defence (the sandbox).

 This discussion reminds me of the days of the Code Red
 vulnerability in IIS (Microsoft web server), and of the
 years of repeated vulnerabilities in Internet Explorer.
 The IIS and IE developers just couldn't bring themselves to
 build in limits to what their wonderful software could do.
 But a web site might need a 100KB URL with hundreds of '../'

A web browser should be able to handle anything thrown at it in a way
that doesn't compromise security. _Every_ application should be able
to handle anything thrown at it in a way that doesn't compromise

What you're suggesting isn't much different from security through
obscurity. You're relying on the hope that nobody would ever be able
to craft an exploit in under 100 bytes. Security doesn't work like
that. Security needs to be something people can rely on to work every
time, not something that depends on Well, let's hope nobody thinks
of this.

If Vim's modeline security is written correctly and securely then
the length of modeline it can handle safely would depend only on the
amount of memory it wants to allocate to hold it. If it isn't able to
do that then there's no security at all.

  Furthermore, what am I supposed to do if I want a long,
  complicated but legitimate modeline?
 I would like a default high security setting for handling
 modelines. If people want modelines that do complex stuff, I
 would recommend setting a new anything goes option.

ABSOLUTELY NOT! Are you honestly suggesting that to enter a long
modeline you have to disable security? I wouldn't touch an editor
like that.

  I like Perl's approach to untrustworthy data. It's flagged as
  tainted at the point it is read, and anything derived from it
  is also flagged as tainted.
 Perl has to have that system because part of its intended usage
 is to handle data entered into web pages. It's pretty complex
 and has taken years to get right.
 Vim is a text editor - it should not automatically execute code
 in any old file that I might accidentally open.

Perl and Vim have exactly the same requirements: the need to safely
handle code taken from an untrustworthy source. It makes no difference
whether it comes directly from a network or from a disk. (If, like me,
you use Vim as your source viewer for web pages, the need for the same
level of security is obvious.)

Matthew Winn

Re: feedkeys() allowed in sandbox

2007-04-29 Thread Matthew Winn
On Sat, 28 Apr 2007 22:43:23 +1000, John Beckett

 Potentially unsafe means we're pretty sure it IS safe, but
 (for example), it's simply not worthwhile allowing a modeline
 longer than 100 bytes because if another vulnerability were
 ever found, we don't want to make it easy for the attacker.

I don't like the idea of preventing modelines over 100 bytes. To start
with, there's no real logic behind it: it's an arbitrary number pulled
out of thin air, and I put it in the same category as saying it's OK
to use gets() so long as you use a long enough buffer that it'll never
overflow. A modeline that's long enough to allow useful things to be
done is long enough to allow unpleasant things to be done.

Furthermore, what am I supposed to do if I want a long, complicated
but legitimate modeline?

I like Perl's approach to untrustworthy data. It's flagged as tainted
at the point it is read, and anything derived from it is also flagged
as tainted. Tainted information cannot be used in unsafe operations,
ever. From what I've read in this thread Vim does something similar,
but in a way that's less complete. That's the right way to go about
it. Setting an arbitrary limit and hoping it'll have the effect of
improving security is far too optimistic for my tastes.

Matthew Winn

Re: improving encryption in vim

2007-03-20 Thread Matthew Winn
On Mon, 19 Mar 2007 09:22:08 -0600, Josh [EMAIL PROTECTED] wrote:

 There are no patent issues, but there is export issues, I live in the US

The reason I suggested Rijndael is because there are no US export
issues. Not only was it developed in Flanders so implementations
outside the US abound, but also as Rijndael was the winning AES
candidate the export of Rijndael implementations from the US is
explicitly permitted. See the final paragraph of

Matthew Winn

Re: improving encryption in vim

2007-03-19 Thread Matthew Winn
On Sun, 18 Mar 2007 15:57:33 -0600, Josh [EMAIL PROTECTED] wrote:

 The main problem that I see is that adding a strong encryption
 function can have regulation issues. That was the only reason that I
 thought about using the external library is to get around this.

With an algorithm like Rijndael there are no patent issues (and there
is even unencumbered public source code available), and the only
problem is with countries that forbid the use of encryption software. 
I imagine that can be solved in the same way as other conditional
compilation matters are tacked in Vim: putting the code in a separate
file and using a compile-time option to include it where available.

 How secure does the encryption need to be?

Considering that Rijndael offers 128-bit, 192-bit and 256-bit security
with very fast and simple code, it's more a matter of: why would you
bother with anything less than the best encryption you can get?

Matthew Winn

Re: BOF Vim 8 - EncryptLine

2007-01-19 Thread Matthew Winn
On Thu, 18 Jan 2007 11:04:00 +0100, Nicolas Weber

  You are correct, I was thinking of this the other way around. My  
  suggestion would only be security in the sense that someone  
  reading over your shoulder would be prevented from seeing sensitive  
  content in the file (e.g. passwords) and would really only be an  
  extension to folding. No change would be made to the file on disk  
  (e.g. the file would need to be secured on disk using some other  
  external mechanism).
 this can already been done with g?$ (or g?a{ ) if you only want  
 to protect your data from people looking over your shoulders, that's  
 already there.

Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner.

Matthew Winn

Re: BOF Vim 8 - EncryptLine

2007-01-18 Thread Matthew Winn
 John Beckett wrote:
  Suggested new feature:
  Make an easy way to encrypt a secret within a line.
  Then you can have a simple text file to document stuff, with
  embedded secrets. On reading, you only need to enter a key if you
  want to see a secret.
  Example lines before encryption:
  server12 { admin topsecret } any text
  mybank { account 123456789 pin 1234 }
  Example lines after encryption:
  server12 {~8vP09fb3+Pn6+/z9/v8AAwocSE9cDYPAYJUThgE} any text
  mybank {~afSDKoy9saGMCZ91x6F7pHkwdzEcMBoGCSqGSIb3DQEJ}
  When viewing a file with encrypted secrets, it doesn't matter if
  others are shoulder surfing. You only need to get rid of onlookers
  for the short time it would take to enter a key and view a secret in
  the message line (which would not change the file).

I can remember using a mail client that had a feature much like that,
except that blocks of encrypted text in the message were introduced by
a line saying [encrypt]. I forget how they were terminated. I think
it's important to have a more distinctive marker than { and } because
otherwise people will be inadvertently encrypting sections of their C


  DecryptLine reverses EncryptLine, changing the current line. It does
  nothing (apart from display an error) if the result is not
  reasonable (the ciphertext must be a tilde followed by base64, and
  the decryption should satisfy certain sanity checks, and should
  yield printable text starting with a space). This is a safety check
  to avoid losing data if the wrong key is used to decrypt.

Perhaps a safer way is to have a hash as part of the encrypted text.
When the text is decrypted the result is checked against the hash as a
confirmation of validity. Merely detecting printable text is hard
when most characters are printable.

On Thu, 18 Jan 2007 00:21:57 -0600, Robert Lee

 Since this requires the file to contain markup characters on the line, 
 its usefulness is limited in source files where the tags { and } would 
 cause a syntax error and cannot be marked as comments.

I can't think of any reason why this would be useful in source code.
The point of encryption is to protect data, so the data must be
encrypted in the file and revealed on the display (the way Vim already
does it for entire files). Source code must be stored on disk in
unencrypted form or otherwise it can't be used.

You seem to be thinking of this as a way of storing cleartext in the
file but hiding it on the display, which is essentially no security at

 As long as this 
 limitation is acceptable, I think it might me equally as useful and 
 perhaps more simple and intuitive if instead foldmarkers were used 
 along with the fold commands (zc, zo):
 Password fold exposed:
   $admin_password = /*{{{*/ 'maryhadababyitsaboy' /*}}}*/ ;
 Password fold closed:
 +--  1 line: $admin_password = * ; 
 This has some advantages:
  - Count of *'s is indicative of length of hidden area (user can add 
 whitespace padding to obscure when desired)

That's a really bad idea. Anyone who shouldn't know what's there has
absolutely no business knowing how long the obscured text is, and
even those who know the password shouldn't need to care. If you're
performing an assignment like $password = some string you don't
really care what the content of the string happens to be, but only
that it's assigned to a variable.

Matthew Winn

Re: vim -S

2006-08-01 Thread Matthew Winn
On Mon, 31 Jul 2006 16:19:28 -0300, Rodolfo Borges

 I made a file with vim commands, starting with
 #!/usr/bin/vim -S
 so I can execute the file directly, instead of using vim -S file.
 The problem is that vim tries to execute this first line too.
 Can we have a workaround on this?
 Like, ignoring #! at the start of a command, instead of giving the
 no ! allowed error?
 Or am I having it all wrong?

One way is to create a file that is both a valid shell script and
a valid Vim script by starting the file with the following line:

exec vim -S $0 $@
[vim commands go here]

(That's a dollar-zero after the -S, not dollar-capital-O.)  When the
shell runs this file it sees the exec command and runs Vim.  Because
$0 is the name of the script Vim opens the script and executes it,
but it ignores the first line because it sees it as a comment.

Matthew Winn

Re: scrolloff enhancement wish

2006-07-21 Thread Matthew Winn
On Fri, Jul 21, 2006 at 10:02:10AM +0200, Bram Moolenaar wrote:
 Yakov Lerner wrote:
  How about adding the option 'scrollfix'  [to the todo.txt],  which
  would fix the cursor on fixed line, in percantage 0-100.
  Value ':set scrollfix=50' would work like ':set scrolloff=999'.
  Value ':set scrollfix=67' would fix cursor 2/3 from top of screen.
  Value ':set scrolloff=0' would keep cursor at top line of screen.
  Value ':set scrolloff=100' would keep cursor at bottom line of screen.
 As you say, you can already do most of this by setting 'scrolloff' to
 a large number.
 If the cursor is really fixed at one position then using j would mean
 that the cursor remains in the same position and the text scrolls.
 That goes against what most people expect.  I think it's not all that

I've had some situations where such a feature would be useful.

A few weeks ago I was working with a large file containing many long SQL
statements mixed in amongst other stuff.  I was searching for the start
of each statement, and it would have been very useful if I could have
arranged it so that each search resulted in the cursor appearing a couple
of lines from the the top of the screen with the SQL statement filling
the space below it.

In this case I set scrolloff to 100 so the start of each SQL statement
was centred, but that gave me half a screen of context above the cursor
when only two or three lines would have done, and caused the ends of the
longest SQL statements to disappear below the bottom of the screen.

I suppose there might be some way to map all the movement commands to
reposition the current line to a certain place on the screen, but at the
time I was doing all this it was quicker to scroll the text each time
than it would have been to write all the necessary mappings.

 And we have too many options already...

Too many options?  Is that possible?

Matthew Winn ([EMAIL PROTECTED])

Re: All mails lost

2006-06-07 Thread Matthew Winn
On Wed, Jun 07, 2006 at 11:33:09AM +0200, Mathias Michaelis wrote:
 My emails are systematically filtered out. I can't even unsubscribe
 (why be on a list where own, very carefully composed contributions
 aren't desired?). I already have phoned to my ISP, and he's innocent.

I'm seeing your messages on the list.  There have been situations in the
past where the list has silently discarded messages because they don't
match some arbitrary unpublished criterion, but that doesn't appear to
be the case here.

[cc'd to poster to be certain the message gets through]

Matthew Winn ([EMAIL PROTECTED])

Re: 7.0 administrivia

2006-05-09 Thread Matthew Winn
On Tue, May 09, 2006 at 04:44:32PM +0200, Nikolai Weibull wrote:
 On 5/9/06, Matthew Winn [EMAIL PROTECTED] wrote:
 On Tue, May 09, 2006 at 02:02:24PM +0200, Nikolai Weibull wrote:
  Well, there's always the following algorithm to consider:
  if (bram_is_unreasonable) {
   int new_child = fork();
   if (new_child) {
 // Let Bram continue in his thought-process
   // Ah, this is now our little baby
 And if fork() returns -1?
 It's obvious, isn't it?

Yes.  The poor little baby never gets conceived.  You should at least
issue a warning, or possibly loop until conception occurs.

P.S. Don't try this with vfork().

Matthew Winn ([EMAIL PROTECTED])