On Wed, Aug 02, 2017 at 01:00:47AM +0200, Christian Ridderström wrote: > 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".
I will not be assigning weights to votes. We can restrict who votes (e.g. those who participate in a discussion), but assigning subjective weights does not seem like a good idea to me. There are ways to improve the vote for next time, and I will write some ideas down and ask for feedback on them. From what I see, you have great knowledge and experience with security. If the above comment is because I did not reference you when I counted the votes, all I can say is that it was a mistake. > 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. This is a good idea, I think. We do have a features repository. I think part of it is that I did not expect it to be such a long discussion. It snowballed. > Perhaps there's other more practical things we could've done to make life > easier. Thanks for starting this discussion. I would like to spend more time on reflection, but I also want to spend time on addressing issues needed to get beta1 out. > [*] 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. I'm glad you bring this experience to the discussion. You can provide a unique view that the rest of us might not see. Scott
signature.asc
Description: PGP signature
