| 1 |
This thread is really out of control, I doubt anything useful can be born |
| 2 |
here, we are just running circles around a chair. |
| 3 |
|
| 4 |
On Fri, 2 Oct 2009 04:54:42 -0500, forgottenwizard |
| 5 |
<phrexianreaper@××××××××.com> wrote: |
| 6 |
> On Fri, Oct 02, 2009 at 11:40:33AM +0200, Sebastian Be?ler wrote: |
| 7 |
>> Am 02.10.2009 11:29, schrieb forgottenwizard: |
| 8 |
>> |
| 9 |
>> Then maybe a "custom_editor"-flag that inserts |
| 10 |
>> |
| 11 |
>> Defaults env_keep += "EDITOR VISUAL PAGER" |
| 12 |
>> |
| 13 |
>> to /etc/sudoers |
| 14 |
>> |
| 15 |
>> With that even emacs users would be satisfied. |
| 16 |
>> |
| 17 |
>> Greetings |
| 18 |
>> |
| 19 |
>> Sebastian |
| 20 |
>> |
| 21 |
> |
| 22 |
> Didn't the maintainer/dev that was dealing with the bug say that he |
| 23 |
> wouldn't do that because it was insecure? |
| 24 |
> |
| 25 |
> That also doesn't fix the problem that sudo thinks that nano is a safe |
| 26 |
> fallback. |
| 27 |
|
| 28 |
The problem is not in the editor, that's just one of the thousand |
| 29 |
assumptions people make here that are incorrect. The developers were rather |
| 30 |
pointing at the use of keep_env in the sudoers file, which is indeed risky, |
| 31 |
and the usage of external variables in the ebuild, which is also not only |
| 32 |
insecure, but very bad from every single viewpoint that I can think of. |
| 33 |
|
| 34 |
And anyway, it's true that vimOS and emacOS are not the sanest and more |
| 35 |
secure editors for config file, since they can do everything, and a bad |
| 36 |
user config for any of these (specially emacs I gues) can put your system |
| 37 |
at risk easier than nano could ever, because nano simply has not the needed |
| 38 |
capabilities to act as a nuclear bomb. But as said, that wasn't the point |
| 39 |
of the developers. |
| 40 |
|
| 41 |
> How about a custom_editor flag, as you suggested, then an EDITOR |
| 42 |
> variable in make.conf? Thats the only way I could see being able to |
| 43 |
> solve this problem without invariably screwing someone. This would |
| 44 |
> provide a fairly sane default while giving the user the choice to use |
| 45 |
> something else. |
| 46 |
|
| 47 |
That would be the only way that it would make sense to me. Just like we |
| 48 |
have VIDEO_CARDS, some GENTOO_EDITOR variable would be nice for this. But |
| 49 |
ebuilds and eclasses would need to be aware of this to push the correct |
| 50 |
dependencies. It's not that trivial to addapt portage to a new portage |
| 51 |
variable. The USE flag idea is non-viable and doesn't make sense. |
| 52 |
|
| 53 |
It really isn't a big deal to configure yourself anyways. So unless some |
| 54 |
developer is interested in this, I doubt they are going to do the job |
| 55 |
unless some pristine and already working patch is sent to them, and someone |
| 56 |
is willing to work on a collaborative way, and not just throwing |
| 57 |
<the-editor-I-preffer> blindingly in the sudo ebuild. |
| 58 |
|
| 59 |
-- |
| 60 |
Jesús Guerrero |
Archives