Re: improving encryption in vim
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 http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html -- Matthew Winn
BUG? line('A) always returns line number in all the files
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file other than the uppercase mark placed, line() should return 0, as
vim 6.3 behaved.
Additional info:
1. Vim version
:version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 20 2007 16:42:33)
Included patches: 1-219
Normal version with GTK2 GUI. Features included (+) or not (-):
-arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui
+diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search
-farsi +file_in_path +find_in_path +folding -footer +fork() -gettext
-hangul_input +iconv +insert_expand +jumplist -keymap -langmap
+libcall
+linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse +mouseshape -mouse_dec +mouse_gpm -mouse_jsbterm
-mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
+netbeans_intg -osfiletype +path_extra -perl +postscript +printer
-profile
-python +quickfix +reltime -rightleft -ruby +scrollbind +signs
+smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title +toolbar +user_commands +vertsplit +virtualedit
+visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard
-xterm_save
system vimrc file: $VIM/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
system gvimrc file: $VIM/gvimrc
user gvimrc file: $HOME/.gvimrc
system menu file: $VIMRUNTIME/menu.vim
fall-back for $VIM: /home/easwy/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0
-I/usr/lib/g
tk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2
-fno-strength-reduce -Wall -I/usr/X11R6/include
Linking: gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm -l
pangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lXt -lncurses -lacl -lgpm
Press ENTER or type command to continue
Re: Understanding regxp implementation
Hi Bram,Nikolai, I went through the regxp code and have a few questions... First, Why use this kind of a coding scheme and encode patterns rather than using a state diagram ? ( Performance/Memory ? ). Secondly, is it a requirement that the new implementation has to follow the same method ? I mean, can't I use a state diagram ( which is easy to implement in my opinion ) to simulate the NFA ? PS: My questions might be incomplete, My understanding of the current implementation is limited; I'll be asking few dumb questions here and there, please excuse me for that.. - Asiri
Re: trying to :vs ./ breaks vim when the window is already split.
Stuart Powers wrote: I opend a file in vim: vim WineComplianceVarietal.txt then I typed: :vs /DI_Pernod/data/pernod/product.txt which successfully split the window. then I typed: :vs ./ upon which I saw: www.stuism.com/temp/vim_split_bug.png Actually, this screenshot was taking after hitting [ENTER] a few times. But I've recreated it a bunch of times by doing the above steps. I believe the system is DEBIAN LINUX [EMAIL PROTECTED] ~ $ uname -a Linux ir7.dimins.com 2.6.8-12-amd64-k8-smp #1 SMP Mon Jul 17 00:17:20 UTC 2006 x86_64 GNU/Linux VIM INFO BELOW: -- :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Jul 14 2006 03:39:57) Compiled by [EMAIL PROTECTED] Please include patches. There were a couple of fixes for ml_get errors related to directory browsing. You may also want to get an updated version of the netrw plugin. -- Did you ever stop to think... and forget to start again? -- Steven Wright /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG? line('A) always returns line number in all the files
Easwy Yang wrote:
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file other than the uppercase mark placed, line() should return 0, as
vim 6.3 behaved.
This is actually documented. The idea is that you can use line('A) to
check if the mark 'A is set. To find out what buffer the mark refers to
use the getpos() function.
--
ARTHUR: Listen, old crone! Unless you tell us where we can buy a shrubbery,
my friend and I will ... we will say Ni!
CRONE: Do your worst!
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: improving encryption in vim
Matthew Winn wrote: 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 http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption (64-bit symmetric keys, other limits for public-key/elliptic algorithms), then it _is_ subject to export restrictions. As the linked page says, it is exportable, but subject to a one-time review prior to export. It doesn't matter if all it does is call a subroutine that was developed in another country or even if the library itself was subjected to review and approval (e.g. see Legal Notices at http://aescrypt.sourceforge.net/). The regulations are at http://www.bis.doc.gov/encryption/Default.htm However, starting in June, 2002, the notification for Publicly Available Encryption Source Code (open-source) is very simple, just submitting the URL. See http://www.bis.doc.gov/encryption/PubAvailEncSourceCodeNofify.html But, on the other hand, the code is not supposed to be exported to certain countries. Mozilla says (currently Cuba, Iran, Libya, North Korea, Sudan and Syria) (http://www.mozilla.org/projects/security/pki/src/download.html). See also http://www.mozilla.org/crypto-faq.html Including AES in vim might require that mirror servers in the U.S. set up IP range blocking for these countries. I don't know, I am not a lawyer. Note that I am not arguing that the export regulations make sense or are effective! Blowfish is only 56 bits, so it is not subject to export regulations. It is probably unbreakable to anyone except the NSA or the equivalent in resourceful foreign countries. (That is, if you choose your keys well.) A determined attacker _might_ be able to break it, but there are usually simpler ways of getting information (malware, hardware key loggers, etc.). If you don't think that Blowfish is sufficient, please explain why and specify what kind of threat you are trying to protect against. Ken Hirsch P.S. It's also really easy to use external commands for encryption. See gnupg.vim at http://www.vim.org/scripts/script.php?script_id=661 Or, if you have OpenSSL installed, you could do something like this: :augroup aes256 : autocmd! : autocmd BufReadPre,FileReadPre*.aes set bin : autocmd BufReadPost,FileReadPost*.aes '[,']!openssl enc -d -aes-256-cbc : autocmd BufReadPost,FileReadPost*.aes set nobin : autocmd BufReadPost,FileReadPost*.aes execute :doautocmd BufReadPost . expand(%:r) : autocmd BufWritePost,FileWritePost*.aes !mv afile afile:r : autocmd BufWritePost,FileWritePost*.aes !openssl enc -e -aes-256-cbc -in afile:r -out afile : autocmd FileAppendPre*.aes !openssl enc -d -aes-256-cbc -in afile -out afile:r : autocmd FileAppendPre*.aes !mv afile:r afile : autocmd FileAppendPost*.aes !mv afile afile:r : autocmd FileAppendPost*.aes !openssl enc -e -aes-256-cbc -in afile:r -out afile :augroup END
Re: improving encryption in vim
On Sun, Mar 18, 2007 at 08:55:33PM +0100, Bram Moolenaar wrote: Main issue is that the current encryption is breakable. We need a stronger encryption, which is free to distribute. We only need one new method. If a strong encryption algorithm is used, the keys may still be the weak spot. A plain assword will be breakable, but it is convenient and probably good enough in many cases. However, if it should be possible to use for business secrets it may be necessary to allow for the key to be stored in a separate file. I see no reason to choose anything else than AES (FIPS-197, Rijandel). It's probably the most well analyzed block cipher today. I don't think it makes any sense to choose a breakable algorithm just to avoid export restrictions, then it would be just as good to keep the current methods instead. It seems better to make sure that the code is developed in a country with sensible export laws, and not reexported from any country with unreasonable laws. Someone mentioned padding - all block ciphers operate on blocks of data, but the mode of operation used determines whether padding is needed or not: http://csrc.nist.gov/CryptoToolkit/modes/ Blowfish was mentioned. It does not use 56 bit keys but it can use up to 448 bits (56 bytes). It uses 64 bit blocks. I don't think there are any known weakness, but I think AES is a better choice (it uses 128, 192 or 256 bit keys and a block size of 128 bits). But as I mentioned, the difficult thing will be to come up with a good way to handle keys. It may also be a good idea to use some integrity check. Andreas
Re: improving encryption in vim
Hi, To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption isn't vim exported from the Netherlands? Nico
Fwd: BUG? line('A) always returns line number in all the files
Sorry for sending to Bram's private mail address.
Here's my original mail.
-- Forwarded message --
From: Easwy Yang [EMAIL PROTECTED]
Date: 2007-3-21 上午9:19
Subject: Re: BUG? line('A) always returns line number in all the files
To: Bram Moolenaar [EMAIL PROTECTED]
Yes, it is! Sorry for the misinformation.
BTW, there's a mistake in the document, about col() function, the line
To get the line number use |col()|.
^^^
should be
To get the line number use |line()|.
2007/3/20, Bram Moolenaar [EMAIL PROTECTED]:
Easwy Yang wrote:
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file other than the uppercase mark placed, line() should return 0, as
vim 6.3 behaved.
This is actually documented. The idea is that you can use line('A) to
check if the mark 'A is set. To find out what buffer the mark refers to
use the getpos() function.
--
ARTHUR: Listen, old crone! Unless you tell us where we can buy a shrubbery,
my friend and I will ... we will say Ni!
CRONE: Do your worst!
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: improving encryption in vim
Ken Hirsch wrote: [...] To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption (64-bit symmetric keys, other limits for public-key/elliptic algorithms), then it _is_ subject to export restrictions. As the linked page says, it is exportable, but subject to a one-time review prior to export. It doesn't matter if all it does is call a subroutine that was developed in another country or even if the library itself was subjected to review and approval (e.g. see Legal Notices at http://aescrypt.sourceforge.net/). The regulations are at http://www.bis.doc.gov/encryption/Default.htm [...] Vim is exported from the Netherlands, not the US. Bram is a Dutch national, now living in Zurich (Switzerland) but during most of the time in which he developed Vim, he lived in Venlo (The Netherlands). The Vim ftp servers are hosted by ftp.nluug.nl (a server in the Netherlands). Best regards, Tony. -- Democracy is also a form of worship. It is the worship of Jackals by Jackasses. -- H. L. Mencken
