Tue, 27 Jul 2021 07:31:12 -0700 - Josef Grosch <jgrosch@???>:
> On 7/26/21 11:26 PM, tito via Dng wrote:
> > On Mon, 26 Jul 2021 22:53:02 -0400
> > Steve Litt <slitt@???> wrote:
> >
> >> Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> >>
> >>> On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> >>>> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> >>>>
> >>>>
> >>>>> My feeling is, that you can not simply teach someone how to write
> >>>>> safe software.
> >>>> Why not? You can teach a person to do anything else. But maybe not
> >>>> in college, because college is built to make money, not to teach.
> >>>> Consider the average textbook and compare to the average "For
> >>>> Dummies" book. The former makes the subject matter look incredibly
> >>>> complex, justifying the professor. The latter makes it easy to
> >>>> learn.
> >>>>
> >>>> What is needed is a curated document explaining the five or ten or
> >>>> twenty things you need to do to be secure, and then how to achieve
> >>>> them in a practical world. Let's start with input field cleansing
> >>>> and protection from errant pointers and buffer overflow. There are
> >>>> many more:
> >>> Knowing you, you probably already have a draft of such a document
> >>> lying around.
> >> Not that I know of. That's why I'm starting at the level of a simple
> >> list.
> >>
> >> SteveT
> >>
> >> Steve Litt
> >> Spring 2021 featured book: Troubleshooting Techniques of the
> >> Successful Technologist http://www.troubleshooters.com/techniques
> > Hi,
> >
> > Ten Commandments
> >
> > 1) use the least amount of code possible
> > 2) try harder and go to point 1
> > 3) if the code doesn't fit into one screen go to point 2
> > 4) always initialize your vars at declaration time
> > 5) always set your vars to NULL after freeing them
> > 6) always check error codes of the functions you call and something
> > appropriate 7) add comments about what and why you did (that ugly hack)
> > 8) use meaningful (to others) names for your functions and vars
> > 9) your code must be readable to others like a children's book
> > 10) if you don't know how to solve it, look what others did, then do
> > it your way (or forget Ctrl-C)
> >
> > these are the few rules I used when I did a little programming in the
> > past. So tell me yours...
> >
> > Ciao,
> > Tito
> >
>
> I've done a fair bit of programming in my career, (FORTRAN, COBOL, C,
> Pascal, Java, Perl, Python) and I've also have my rules to programming.
>
>
> 1) KISS (Keep It Simple Stupid) Clever code always comes back to bite
> you in the ass. Simplicity is a beautiful thing.
>
> 2) White space is free, use it to make the code readable.
>
> 3) Pick a coding style and stick to it, I personally prefer the One True
> coding style. Most languages have a tool like Beautify that can be
> configured to format your code to your coding style.
>
> 4) If a block of code gets repeated 2 or more time break it out as a
> function or a method.
>
> 5) Most languages have a Lint type tool, use it often.
>
> 6) Use the system and languages libraries. Never try to re-write them,
> it will only lead to more bugs and rabbit holes. Same goes for libraries
> from other projects, they have had the benefit of many eyes looking at
> their code.
>
> 7) Pay attention to the scope of variables and functions.
>
> 8) Use a revision control system like Git to check code in on a regular
> basis into a branch for a coding session, not into the main branch.
> Working in a branch lets you figure out what really works and only when
> everything is correct then merge into the main branch. I usually do a
> pull at the beginning of a coding session and a push at the end.
>
>
> I'm sure I have more but I'm low on coffee.
9) Write code to debug and log
10) Handle all kind of errors
11) Document and document and document all the code (vars, functions,
errors etc. ... all)
12) Write and run accurate tests for each routine and the whole code
13) Clearly specify the license(s) for each piece of code
... sure there is more but now I am low on coffee too...
regards
al3xu5
--
Say NO to copyright, patents, trademarks and industrial design
restrictions!
____________________________________________________________________________
Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B
::
Re: [DNG] Nasty Linux systemd secur…
