Richard wrote:
> We have spent an enormous amount of time on this ...
>
Hi,
Some thoughts regarding the discussion of safety and design of security
measures, i.e. a kind of "lessons learned" regarding the discussion aspects.
I think one thing that made things slower and more inefficient was a lack
of any self-contained description[*] of the overall design regarding safety
and security. Ideally I think the discussion would've benefited from having
one for:
- LyX version 2.2, i.e. the release with the big problems
- What was in master/HEAD, and at least was on its way to become LyX 2.3
- Intended eventual design, for LyX 2.3 or possibly a later release.
The long threads likely by now do contain a lot of separate pieces of
description, but it's unfortunately not so easy (at least for me) to find
this information among all the posts.
And sometimes I'd probably not understand to which "release" the
information pertains.
A partial "fix" might be to create a "best of"-list of posts with useful
descriptive information. Or perhaps to copy them to into one place, adding
minor markup as to what's still valid.
Or actually try to write down some design design description.
Question: Is there anyone who feels they know/understand the big picture
regarding safety/security?
Because I guess we in theory instead of writing things down could have a
designated "guru".
Actually, I'm a little worried that no one really has the big picture of
the intended design regarding safety and security.
Also, that different people have different ideas of where we are going and
what's considered needed, while we at the same time are not aware of these
differences.
For something (a "feature") much less complicated than safety/security, I
think it'd be fine for LyX if only a very small number of people know that
part, and to where they intend to go. And that everything else is in the
code. But for a complicated topic like safety, and when asking people to
vote, I think the lack of a description is a problem.
Hmm, and perhaps in case of votes, Scott should (be allowed to) weigh them
differently depending on the persons knowledge. E.g., since I don't
know/understand the (intended) safety design, why should my vote count as
much as a potential safety "guru".
On a more practical level:
Hindsight is 20-20, but regarding e.g. Enrico's patch, perhaps we should
have created a branch representing that alternative? This would have
allowed that branch to always represent the latest improvement, thus
avoiding people testing out an older patch accidentally.
So we should keep the possibility of using branches in mind for future
discussions.
Perhaps there's other more practical things we could've done to make life
easier.
Best regards,
/Christian
[*] Regarding SW design descriptions and actually being able to understand
and review an intended design in advance, I'm probably a bit "damaged" from
when I worked with satellite software (AOCS), e.g. as SW verification and
validation manager.
In that field, lots of documentation was required which often was annoying,
but for complicated stuff like FDIR (making the SW/satellite be able to
cope with equipment failures), it really was essential to have the overall
picture. The reason being that a tiny change in one area of the system
could easily cause big problems in other areas, i.e. it's about unintended
consequences.
Here I see several similarities between FDIR and the safety/security for
LyX, e.g. that adding a neat feature like previews of Gnuplot figures
could've led to a big security hole.
Another similarity is that you can't do FDIR only at a low level, you need
a system perspective.
I think it's the same with safety/security for LyX: If we only consider
each feature separately, we're going to screw up. Two features in isolation
might be safe, but when available together it might "leak".
Another similarity is needing to define our objectives, and what we
consider "good enough" safety. If we don't understand what we're trying to
achieve, it's e.g. not possible to review a design to see if it achieves
the objectives.
