Re: [elinks-dev] witekfl branch status
On Sun, Mar 25, 2007 at 11:23:30PM +0300, Kalle Olavi Niemitalo wrote: > Witold Filipczyk <[EMAIL PROTECTED]> writes: > > > On Sun, Mar 18, 2007 at 09:12:23PM +0200, Kalle Olavi Niemitalo wrote: > >> bug620 This resets forms when I resize the window. Not acceptable. > > It's difficult because it should be done only once when the document is > > fully loaded after reloading, but the user might type something into forms > > earlier. > > How to do that? > > Why must the forms be reset only after the document is fully > loaded? I think it would be simplest to discard all form-related > information immediately in reload(), before even requesting the > file from the server, and let the renderer then incrementally > rebuild the data, as if loading the document for the first time. > I am however not familiar with this code, and it seems I'll need > a diagram to properly understand all of the pointers between its > different structures. You are right! ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk <[EMAIL PROTECTED]> writes: > On Sun, Mar 18, 2007 at 09:12:23PM +0200, Kalle Olavi Niemitalo wrote: >> bug620 This resets forms when I resize the window. Not acceptable. > It's difficult because it should be done only once when the document is > fully loaded after reloading, but the user might type something into forms > earlier. > How to do that? Why must the forms be reset only after the document is fully loaded? I think it would be simplest to discard all form-related information immediately in reload(), before even requesting the file from the server, and let the renderer then incrementally rebuild the data, as if loading the document for the first time. I am however not familiar with this code, and it seems I'll need a diagram to properly understand all of the pointers between its different structures. pgpZzVKsci9YD.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk <[EMAIL PROTECTED]> writes: >> ?2007-03-09 c09cc0398fb1c10c99076524782eee6c1e45fcef fsp: download >> resuming >> ?2007-03-09 967a15b7f4427dc94ddd9fe1092f6a20104caa2a smb: download >> resuming > When one aborts dowload, may resume it later. > It works for http and ftp, why not do it for fsp and smb? The question marks just meant I haven't yet examined the patches in detail. I am sorry I did not mention this. If the implementation is correct then surely these changes should go in. pgpgTBJHZrcFc.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
On Sun, Mar 18, 2007 at 09:12:23PM +0200, Kalle Olavi Niemitalo wrote: > bug620This resets forms when I resize the window. Not acceptable. It's difficult because it should be done only once when the document is fully loaded after reloading, but the user might type something into forms earlier. How to do that? > > bug629This gives users an incentive to enable ECMAScript support, > which currently has bug 755, which can crash ELinks and may be > exploitable for worse effects. I think that should be fixed > before any new ECMAScript features are added. I committed "delayed submitting forms". I hope this help. > decompr This sets conn->stream_pipes_written = 0 after read_encoded > returns > 0. But read_encoded is not guaranteed to read all > the data from the pipe. So the comment in struct connection > is not accurate. Yes, It hung with bzip2. > > delay delayed_goto_uri, apparently prevents some internal errors > with copiousoutput, but I haven't yet examined why. > More importantly, delayed_open.ses may become a dangling > pointer if the tab is closed before the bottom half gets > to run. One possible fix might be to define a struct > weak_session that has a reference count, bidirectionally link > that with struct session, and tear down the link when the > struct session is freed. Furthermore, the return value from > register_bottom_half should be checked. I don't believe it. Show me a recipe to crash ELinks with copiousoutput. > > In the long term, I'd like to have the copiousoutput code > rewritten as an encoding-like layer, so that it can stream > data to the viewer as it comes from the network. This is less > important than the SGML/DOM integration though. > > epoll I don't think this should be merged. > If ELinks has to keep supporting select() too, I think the > maintenance burden outweighs any advantages epoll may have. > It may be faster; but I don't believe the speedup is > noticeable in practice. It is not limited by FD_SETSIZE; > but threads[] still has that limit. This is the only code that works fine. > > mergedThese have already been merged to master. > > revertw These have been reverted in the witekfl branch or revert > commits that won't be merged. > > spaces2 Security risk; see Debian bugs 90483 and 221717. > If the % does not already have apostrophes around it, this > quotes the file name with add_shell_quoted_to_string; else, > this adds the file name as is. In the latter case, if there > are apostrophes in the file name too and backquotes between > them, arbitrary programs can be executed without the user > knowing. If ELinks used add_shell_safe_to_string instead of > substituting the file name directly, then it still wouldn't > handle spaces correctly on Debian, but I think it would be > good enough. So? > > speechTest backspaces and add a charset option before merging. > write_to_festival now recodes text to the terminal I/O > charset. I think it will be very common to use UTF-8 I/O with > the terminal but an ISO-8859-based voice with Festival, and > write_to_festival currently does not support that combination. > Also, it should check for SCREEN_ATTR_FRAME. Frame chars are ignored. I'm too lazy to do the rest. > ? 2007-03-15 6605f4c471a8b2a1408552a4fdd34b2798756558 read_special: > s/foreachback/foreach/ add_to_list adds to the beginning of the list, so the foreach will find faster than the foreachback. > ? 2007-03-14 823c26748a9b6ade0bbcfa9950e8daadb0cc9acf delayed_goto_uri: > Do not segfault when there is no location yet. ELinks crashed when run with the 'copiousoutput' file from the command line. > ? 2007-03-14 82a408da280a3e7a05975d28a9b0701e76688396 read_special: Added > no-cache. Without this was the memleak and fds of popen_data weren't closed. > ? 2007-03-14 fbc51b399113224bc0247c9ef6ea773cc06ea12a read_special: > reorganization of code. > ? 2007-03-13 b9c409c3b9ea2ae01797c192f0ebda524577d7db I forgot about > conn->popen. > ? 2007-03-13 7ab5b8d57ecfe0e25e6185ec85304003e5c02024 copiousoutput: > Allow read only registered file descriptors. Reading from any /dev/fd/* may hang ELinks eg. from /dev/fd/0, so only fds of the 'copiousoutput' are used. BTW, whether reading of /dev/zero should be allowed? > ? 2007-03-13 a494f376f998e69e92125e8f13b9147e37b55799 copiousoutput: Use > current frame. Frames are used where they appears. > ? 2007-03-13 b6e862f539c6181dacee921ee7120aee76f83245 forms: allow submit > empty forms This and delayed_submit_forms let me get to my bank account. > bug6292007-03-13 bd0aa20c9c10c5073291a9bd99cddf883bb7857b Grammar. > spaces2 2007-03-12 6a77f68c63497b518b07fb449984d018f02030db mime: Check
Re: [elinks-dev] witekfl branch status
On Thu, Mar 15, 2007 at 07:09:45AM +0200, Kalle Olavi Niemitalo wrote:
> Witold Filipczyk <[EMAIL PROTECTED]> writes:
>
> > On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote:
> >> acckey This seems to fix a bug; please advise how to reproduce the bug.
> >
> >
> > Start
> >
> >
> >
> > And ALT-A doesn't work.
>
> I saved that HTML in a file and opened it with ELinks 0.12.GIT
> (026e56d539099477043e499b1a7227c5a67e200f) running with the
> English language. I have bound move-cursor-{down,left,right,up}
> to {j,h,l,k}. My document.browse.accesskey.priority setting is 1.
>
> I moved the cursor down from the link and pressed Alt+a. The
> cursor jumped back to the first character "S" of the link. I
> pressed Alt+a again; this did nothing. I moved the cursor three
> steps to the right, to the "r", and pressed Alt+a once more; this
> did nothing either. I again moved the cursor down and pressed
> Alt+A (note capital A). This did nothing.
>
> I then tested c2d1952a082e2ed51dbfb6895f29c0869a89a8a3 from the
> witekfl branch in the same way. The only difference I could see
> was that in this version, when the cursor was already on some
> character of the link, pressing Alt+a moved it to the beginning
> of the link, rather than left it in place as in master. Is this
> the bug you were fixing?
Set document.browse.accesskey.auto-follow to 1 and try again.
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk <[EMAIL PROTECTED]> writes:
> On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote:
>> acckey This seems to fix a bug; please advise how to reproduce the bug.
>
>
> Start
>
>
>
> And ALT-A doesn't work.
I saved that HTML in a file and opened it with ELinks 0.12.GIT
(026e56d539099477043e499b1a7227c5a67e200f) running with the
English language. I have bound move-cursor-{down,left,right,up}
to {j,h,l,k}. My document.browse.accesskey.priority setting is 1.
I moved the cursor down from the link and pressed Alt+a. The
cursor jumped back to the first character "S" of the link. I
pressed Alt+a again; this did nothing. I moved the cursor three
steps to the right, to the "r", and pressed Alt+a once more; this
did nothing either. I again moved the cursor down and pressed
Alt+A (note capital A). This did nothing.
I then tested c2d1952a082e2ed51dbfb6895f29c0869a89a8a3 from the
witekfl branch in the same way. The only difference I could see
was that in this version, when the cursor was already on some
character of the link, pressing Alt+a moved it to the beginning
of the link, rather than left it in place as in master. Is this
the bug you were fixing?
pgp3UWGSEuOGq.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes: > - Automatically detect whether and how the string has been > quoted, and adapt. This detection cannot be based solely on > whether the system is Debian, because the user's ~/.mailcap > may contain entries that are quoted differently. Also, if > the % is nested deeply inside backquotes and such, it may > not be obvious what should happen. In such cases, it would > be best to give an error message. It is also possible to construct shell commands where parsing the quotes correctly requires recognizing "case" statements. echo "$(case "$EDITOR" in emacs) echo "%s'" ;; esac)" \' If the parser thinks the $() ends at the first closing parenthesis, it will seem that the %s is not quoted at all. In reality though, %s is inside "" inside $() inside "", and metacharacters should be escaped as if inside only "". Bash 3.1.17 doesn't get this right (Debian bug 86397); dash 0.5.3 does. Which perhaps implies that people are unlikely to actually use such constructs in mailcap files. This may eventually get fixed in Bash, however. pgpyNuaAaLzgq.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk <[EMAIL PROTECTED]> writes:
> On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote:
>> spaces2 "Decode %20 in local filenames and enclose them with '"'."
>> This seems suspicious. What if there is '"' or '\' in the
>> filename? There is add_shell_quoted_to_string for such
>> purposes.
>
> Fixed. Thanks.
> spaces2 handles mailcap entries like this:
> application/x-tar; /bin/tar tvf -; print=/bin/tar tvf - | print text/plain:-;
> copiousoutput
Unfortunately, it seems this patch is not safe to apply. The
problem is that Debian's update-mime program automatically
changes %s to '%s' in mailcap entries. See Debian bugs 90483 and
221717. When ELinks' add_shell_quoted_to_string adds another
pair of single-quotes around the file name, the quotes cancel
out, and metacharacters in the file name can then cause the shell
to run arbitrary programs.
In RFC 1524, there is a sentence about mailcap %{parameter}
expansions: "The entire parameter should appear as a single
command line argument, regardless of embedded spaces." This
might be interpreted to mean that Debian does wrong. Still,
opening a security hole here would be a disservice to ELinks
users, even if it's really Debian's fault. The current code
passes the URL-encoded filename, which prevents spaces from
working, but also restricts the set of metacharacters available
and so prevents some (perhaps all) attacks.
There are a few ways to make the spaces work:
- Automatically detect whether and how the string has been
quoted, and adapt. This detection cannot be based solely on
whether the system is Debian, because the user's ~/.mailcap
may contain entries that are quoted differently. Also, if
the % is nested deeply inside backquotes and such, it may
not be obvious what should happen. In such cases, it would
be best to give an error message.
- Copy even local files to temporary files and ensure that the
name of the temporary file contains only safe characters and so
does not need to be quoted. If the temporary file is created
in $TMPDIR and $TMPDIR already contains unsafe characters, then
ELinks should refuse to run the MIME handler.
- As above but make hard or symbolic links instead of full copies.
- Disable mailcap support so that the user must manually specify
all MIME handlers in ELinks, and tell the user not to put
quotes around the % placeholder.
pgpdsssogJsRO.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Witold Filipczyk <[EMAIL PROTECTED]> writes: > Do you think that maintaining 3 versions of ELinks is reasonable? With this few people hacking on ELinks, I think it would be better to maintain just one stable and one development branch. Thus, the ELinks 0.10 branch should be dropped now, and the ELinks 0.11 branch should be dropped when 0.12.0 is released. (There should first be some release candidates, though.) Fonseca, you're the maintainer; do you authorize this? When a security vulnerability is found, I think it is good to test for it in many released versions, even ones that are no longer maintained and won't be fixed. pgpXQCNTDdO7V.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote: > acckeyThis seems to fix a bug; please advise how to reproduce the bug. Start And ALT-A doesn't work. "Start iterating from the next link": Where there is more links with the same accesskey only the first one was accessible via accesskey. I think starting from the next link is just. > > bug844Needs review and testing. > > bug916Needs review and testing. > > bug927Will merge. > > bug935If you test this with UTF-8 then I'll merge it. > > epoll I don't think this should be merged. > If ELinks has to keep supporting select() too, I think the > maintenance burden outweighs any advantages epoll may have. > It may be faster; but I don't believe the speedup is > noticeable in practice. It is not limited by FD_SETSIZE; > but threads[] still has that limit. > > fsp Needs review and testing. > > gpm Please add some documentation into gpm-wheel.patch. > Does the patch fix a bug in GPM? > Can it hurt compatibility with programs that use libgpm? > > mergedThese have already been merged to master. > > nonblkThis makes local CGI pipes use nonblocking I/O. Not > using nonblocking I/O is a bug, and local CGI was added > in ELinks 0.9.0. Thus, the stable releases ELinks 0.10.6 > and 0.11.2 may also have this bug. Please add the bug to > bugzilla.elinks.or.cz so that backports can be tracked. > > spaces1 "ftp didn't handle filenames with spaces." > Does it work in 0.10.6 and 0.11.2? If not, please add > this to bugzilla.elinks.or.cz. Do you think that maintaining 3 versions of ELinks is reasonable? > > spaces2 "Decode %20 in local filenames and enclose them with '"'." > This seems suspicious. What if there is '"' or '\' in the > filename? There is add_shell_quoted_to_string for such > purposes. Fixed. Thanks. spaces2 handles mailcap entries like this: application/x-tar; /bin/tar tvf -; print=/bin/tar tvf - | print text/plain:-; copiousoutput Witek ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
On Sun, Feb 25, 2007 at 12:14:35PM -0600, Kenny Hitt wrote: > Hi. > > On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote: > > > > speech Needs a use case and review. Could then be merged before > > 0.12pre1. > > Is this intended to help blind people? I believe they > > usually have screen reader programs; why is this better? > > The code may also cause compilation errors on non-POSIX > > systems but I think we can sort those out based on test > > reports if there is a 0.12pre release after the merge. > > I can't speak for other blind people, but I use a screen reader for access to > elinks. I would also like to know why this feature was added and why it is > better than using my screen reader. This feature does not collide with screen readers. I just want to listen to ELinks sometimes. Witek ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
Hi. On Sun, Feb 25, 2007 at 10:52:47AM +0200, Kalle Olavi Niemitalo wrote: > > speechNeeds a use case and review. Could then be merged before > 0.12pre1. > Is this intended to help blind people? I believe they > usually have screen reader programs; why is this better? > The code may also cause compilation errors on non-POSIX > systems but I think we can sort those out based on test > reports if there is a 0.12pre release after the merge. I can't speak for other blind people, but I use a screen reader for access to elinks. I would also like to know why this feature was added and why it is better than using my screen reader. Kenny ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] witekfl branch status
acckey This seems to fix a bug; please advise how to reproduce the bug. bug844 Needs review and testing. bug916 Needs review and testing. bug927 Will merge. bug935 If you test this with UTF-8 then I'll merge it. epoll I don't think this should be merged. If ELinks has to keep supporting select() too, I think the maintenance burden outweighs any advantages epoll may have. It may be faster; but I don't believe the speedup is noticeable in practice. It is not limited by FD_SETSIZE; but threads[] still has that limit. fsp Needs review and testing. gpm Please add some documentation into gpm-wheel.patch. Does the patch fix a bug in GPM? Can it hurt compatibility with programs that use libgpm? merged These have already been merged to master. nonblk This makes local CGI pipes use nonblocking I/O. Not using nonblocking I/O is a bug, and local CGI was added in ELinks 0.9.0. Thus, the stable releases ELinks 0.10.6 and 0.11.2 may also have this bug. Please add the bug to bugzilla.elinks.or.cz so that backports can be tracked. spaces1 "ftp didn't handle filenames with spaces." Does it work in 0.10.6 and 0.11.2? If not, please add this to bugzilla.elinks.or.cz. spaces2 "Decode %20 in local filenames and enclose them with '"'." This seems suspicious. What if there is '"' or '\' in the filename? There is add_shell_quoted_to_string for such purposes. speech Needs a use case and review. Could then be merged before 0.12pre1. Is this intended to help blind people? I believe they usually have screen reader programs; why is this better? The code may also cause compilation errors on non-POSIX systems but I think we can sort those out based on test reports if there is a 0.12pre release after the merge. stpcpy Will merge. bug935 2007-02-23 f571cf509d472d47f5c77a46709a6e64da8ee3f6 bugfix 935: not tested with UTF-8, but you know at least where the bug is. merged 2007-02-23 1bb2c30f8aba0c27292448980d33ef16f51fc96f Used the builtin macro RM in place of defined UNINSTALL. bug916 2007-02-21 4a7b9415e11e2311eec4ffdc277b7023e9a94ef9 MIME: When there is no % in the handler string (no %s in the mailcap entry) spaces2 2007-02-21 469481b2725cd08a51a81ac344fd90749fea109c Decode %20 in local filenames and enclose them with '"'. bug927 2007-02-20 21fd1fd10ff3f53ab670a59610d6530921000e83 Fix the memleak. Part II of the 927 bugfix. bug927 2007-02-20 088db2c3de7b611f669e92bf9974aaac60467c9e The fix for the bug 927. merged 2007-02-18 2a8bff982b2c07d7bc0c73b61f62398e48ba804c Do not show always evaluate as true warnings. merged 2007-02-18 dd34591c7472d0205ca16f9d37e132265bb46376 Revert "Added macro foreach_module_builtin. Killed some warnings of gcc-4.2." merged 2007-02-18 f8c0fe013b86698e6087cc256f0e8fb373a3d5db Revert "Killed warnings: uri_cache always evaluate as true" merged 2007-02-17 dc1b84bafdd3337b80df92fcba7ff3b6d5356658 Do not add LUA_CFLAGS to the CPPFLAGS. merged 2007-02-17 c96ec209c15a8fcfa3027ff9087b27b2a09a3d39 Old CPPFLAGS was stored in CPPLFAGS_X. merged 2007-02-17 a35644bf3ea6e44d3f59d91fd27fe86850153339 Use PERL_CFLAGS only when necessary. merged 2007-02-17 e9a2241b1bdb30e38053508bc89e887260662c29 Do not add GUILE_CFLAGS to the CPPFLAGS. merged 2007-02-17 de73f644baab81696db59b70196003e021eb7e06 Added SEE_CFLAGS to the Makefile.config. Use SEE_CFLAGS only when necessary. bug844 2007-02-17 20048696c8594fa370e06734ca926f20fe998623 smb2: Do not use smb_options. stpcpy 2007-02-15 81ec678499c148ea0005a686f7c395f30d7881e7 stpcpy was not used in this file. merged 2007-02-15 dbd95362979af70193c20d9b2e11c0bc50f641fb Use X_CFLAGS only when necessary. acckey 2007-02-11 c2d1952a082e2ed51dbfb6895f29c0869a89a8a3 accesskey: start iterating with next link. acckey 2007-02-10 5008fb697d93569984e2163c528c6404d36bcfa9 Accesskey didn't work as it should. merged 2007-02-05 f0717304f00435239ea347032a4caf9b2487c21b Killed warnings: uri_cache always evaluate as true merged 2007-02-05 2970056976962757fdddc048bcd67b1f21240d20 Do not pollute CPPFLAGS by PYTHON_CFLAGS. bug844 2007-01-27 e40f37f80c9a9c43000dba6594ee1e97829910bb Typo. bug844 2007-01-27 c7f6f769518916dd76ba1707506be602c61cb011 fsp, smb: remember the username and the password given in the uri. bug844 2007-01-27 9aab8b0cebebd7109be8b3a0bdd359dedae1731f smb: minor optimisation. bug844 2007-01-27 a956a55f8ce276e8f4dd55e1b93bf6c68a4d0c24 smb: Encode and decode spaces in filenames. fsp 2007-01-27 8ef93ebf09bf5afc700568b55b0bb1449ad32551 fsp: call find_auth in both cases. spaces1 2007-01-27 047bf7e1c6c28210c38307d113b6bc1464cdd083 ftp: ftp didn't handle filenames with spaces. fsp 2007-01-27 86789084128aefbcd1c390e51eaf8bda38ebdd19 fsp: used strings, encode and decode filenames with spaces. bug844 2007-01-26 c16c4d06c7f83b708f211cf9b897f637
