Re: Stored procedure code no longer stored in v14 and v15, changed behaviour

On 2022-12-02 14:02:37 +0100, Daniel Gustafsson wrote:
> > On 2 Dec 2022, at 14:00, Pasi Oja-Nisula <pon(at)iki(dot)fi> wrote:
> >
> > On Fri, 2 Dec 2022 at 02:24, raf <raf(at)raf(dot)org> wrote:
> >> Same here. Accessing the loaded stored procedure source
> >> is how I audit the state of stored procedures in the
> >> database against the code in the code repository.
> >
> > Exactly. If our software is audited, how can I reliably prove to auditor
> > that the running version of the procedure has not been tampered with
> > either by customer, rogue developer or some malicious party?
>
> How do you today prove that for other compiled programs in your system?

Generally by storing hashes of the binaries in some tamper-proof way
(for example, the packages may be signed by the distributor). Then you
can compute the hashes of the binaries on your system and compare them
with the known-good hashes.

But that assumes that the binaries that are installed are actually the
binaries which are used. As I understand it, this is not the case here
as the artefact which is sent to the server is the source code which is
then tokenized/compiled and stored by the server. So you can't simply
tell whether the stored/used version corresponds to the code you
installed.

I don't know how reproducable that tokenization process is. Can you just
do it again and compere the results?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"