emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 3d38d1d: Add sqlite3 support to Emacs


From: Andy Moreton
Subject: Re: master 3d38d1d: Add sqlite3 support to Emacs
Date: Mon, 13 Dec 2021 22:35:26 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (windows-nt)

On Sun 12 Dec 2021, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > No, I'm proposing to modify the free plug-ins to define this symbol, and
>   > then to make Emacs to check for it before telling SQLite to load the
>   > plugin.  It would work the same, and it'd also be much easier than
>   > modifying SQLite and having to maintain the modified version, and so on
>   > and so forth.
>
> I don't think that is legally adequate.  I have an idea for a solution
> to that problem, but I need to check it with a lawyer first.
>
> For the mean time, Emacs _should not_ offer any interface to load
> sqlite3 extensions.
>
> But eliminating that is _not_ enough to solve the problem, because
> sqlite3 offers another way to load one!  It defines an SQL function,
> load_extension, to load an extension.  Whatever testing that Emacs
> would try to do on an extension before loading it, load_extension
> would bypass it.
>
> Is there a way we can undefine that SQL function?  The equivalent of
> fmakunbound in Lisp?

Perhaps disabling the SQL extension API would be sufficient ?

The documentation notes that sqlite3_db_config can be used to enable
only the C sqlite3_load_extension API without also enabling the SQL
extension loading API:

    https://www.sqlite.org/c3ref/enable_load_extension.html

The security warning on that page recommends using sqlite3_db_config,
and NOT using sqlite3_enable_load_extension.

    AndyM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]