Matt Tucker <tuck(a)whistlingfish.net&gt; writes: ... Out of curiosity, is it really possible for such a function to work, given the high-level nature of elisp (garbage collection and whatnot)? I wouldn't trust it to do the right thing as far as security is conerned (but I may be paranoid). Not trying to do anything at all might be more sincere, as there wouldn't be a (potentially) false sense of security. The comment in the function doesn't inspire great confidence IMHO.

I think I agree with Simon. If we want to implement "shreddable buffers," it would have to be done in C, they would have to shred on resize, and the XEmacs standard lstream I/O functions could not be used. A "shredding lstream" type could be created, though. Matt> (defun passwd-erase-buffer () Urk. Because the buffers are automatically resized by copying to a newly malloc'd area, if .netrc is bigger than the default buffer size, there may be several memory regions containing partial copies of .netrc lying around. Furthermore there will definitely be Lstream internal buffers containing parts of that file lying around. Since those buffers default to 64kB IIRC, in fact they're likely to contain the whole file. Matt> I was wondering whether the following code could be used to Matt> replace the while loop, although I expect the answer is Matt> "no": Matt> (insert (make-string s ?\000)) This should work just as well as long as a buffer resize is not forced; it should basically amount to a memcpy followed by adjusting the gap parameters. But if it forced a resize, then the buffer containing the dangerous data would simply be abandoned, and the new buffer overwritten with zeros. So what you would have to do would be something like (defun internal-buffer-size-list () "Return list of sizes at which buffer memory is reallocated in increasing order; artificially starts with zero.") (let ((l (internal-buffer-size-list))) (while (< s (car l)) (setq l (cdr l)) (erase-buffer) (insert (make-string (car l) ?\000)))) Obviously this could be optimized a little more. But it definitely doesn't help at all with the problem of Lstream internal buffers hanging around. And you'd have to be very careful to make sure that list got initialized correctly; too small is not a problem, but too big means the buffer will get abandoned before it's shredded. I don't understand why the while loop takes very long, though. Unless something very strange is going on, it seems rather unlikely that more than one buffer resize should occur, meaning that (insert ?\000) (setq s (1- s)) should be very fast and constant time, as insertions are optimized to take place at point. Matt> Otherwise, does anyone have any ideas as to why this might Matt> be taking so long? Are you using Mule? I don't see any reason why \000 should be special, but have you tried with something else? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

MT> Otherwise, does anyone have any ideas as to why this might be taking so MT> long? I bet it goes much much faster if you add (buffer-disable-undo) to passwd-erase-buffer, although that by itself would not be a real fix. The efs folks should probably do (buffer-disable-undo) when visiting the .netrc file for the usual security reasons, and that might be the Real Fix. (All just a guess, as usual)