From: Katsumi Yamaoka <yamaoka@jpl.org>
Cc: TAKAI Kousuke <tak@kmc.gr.jp>
Subject: Re: ELisp-based uncompface
Date: Thu, 12 Feb 2004 13:21:32 +0900 [thread overview]
Message-ID: <b9yoes5nd0z.fsf@jpl.org> (raw)
In-Reply-To: <m37jytugpx.fsf@defun.localdomain>
I'm not sure whether TAKAI Kousuke subscribes this list, so I Cc
this message to him with the whole quotations.
>>>>> In <m37jytugpx.fsf@defun.localdomain>
>>>>> Jesper Harder <harder@ifa.au.dk> wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> I've merged the ELisp-based uncompface program into compface.el.
>> This was written by TAKAI Kousuke (`Kousuke' is his personal
>> name), he is now working on the paper to assign the copyright to
>> FSF. It makes it possible to show X-Face images without the
>> external uncompface and icontopbm programs or the libcompface
>> library.
> Excellent.
Thanks. All praise should go to TAKAI Kousuke.
>> It won't be activated for almost users but you can test it by
>> setting nil to the uncompface-use-external variable if you are
>> interested in it:
>>
>> (setq uncompface-use-external nil)
> It works fine for me and it's fast enough (I guess a lot of effort was
> spent on making it fast).
> If no problems turn up I think the internal decoder should be the
> default.
It's fast enough for me too, however I heard it takes seconds
per image in the slow machine. But now I've changed the default
value for uncompface-use-external to nil. If you aren't
satisfied with the speed, please alter the value. Otherwise, we
can add the caching images mechanism if it is requested.
> The reason is that I trust Lisp code much more than C to not
> have nasty and possibly exploitable buffer overflows.
> Incidentally, I was just discussing attachments and viruses in another
> group, and challenged them to think of any attachment that would be
> unsafe for me to open.
> The only thing they could come up with until now is the temporary file
> bug in x-face-el (which a. hasn't been part of Gnus, b. can't really
> be used for a virus since it was only a local exploit).
> But anyway, it does point to the fact that it would be unpleasant if
> someone found an exploitable flaw in uncompface or icontopbm.
Oh, I see. I hadn't considered problems with external programs.
Thanks again.
--
Katsumi Yamaoka <yamaoka@jpl.org>
next prev parent reply other threads:[~2004-02-12 4:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-12 0:46 Katsumi Yamaoka
2004-02-12 3:19 ` Jesper Harder
2004-02-12 4:21 ` Katsumi Yamaoka [this message]
2004-02-12 5:53 ` Jesper Harder
2004-02-12 6:05 ` Katsumi Yamaoka
2004-02-16 14:04 ` Reiner Steib
2004-02-17 5:59 ` Katsumi Yamaoka
2004-02-18 15:47 ` Reiner Steib
2004-02-18 17:23 ` Ted Zlatanov
2004-02-18 23:00 ` Katsumi Yamaoka
2004-02-13 16:25 ` Xavier Maillard
2004-10-11 23:19 ` Katsumi Yamaoka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9yoes5nd0z.fsf@jpl.org \
--to=yamaoka@jpl.org \
--cc=tak@kmc.gr.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).