Java wissenschaftliches Experiment/Aufgabe

[JavaBeans]

Hi!
Im Rahmen meiner Bachelorarbeit habe ich ein Experiment für Java-Entwickler entworfen. Bist Du bereit, 20 Minuten in die Wissenschaft zu investieren, um die Qualität von Code Reviews zu verbessern? Wenn ja, wäre es toll, wenn Du an unserem Experiment teilnehmen könntest. Achtung, die Sprache ist auf Englisch.
Das Experiment findest du unter folgendem Link:

Intro

Als Dankeschön werden wir in Deinem Namen 5 USD an eine gemeinnützige Organisation deiner Wahl spenden!

 

[Robert Zenz]

In contrast to a classic code review, we are not interested in maintainability or design issues but rather in security issues.

Bedeutet das dass ich mir Kommentare wie "Hier geht try-with-resources" oder "(Fehler-)Meldung koennte besser formuliert sein" oder "Hier verwendet ihr die komplett falsche Klasse" nicht gefragt sind und ich mir die verkneifen soll?

 

[White_Fox]

Es ist nicht oft so, das Probleme mit "maintainabillity" oder "design issues" "security issues" überhaupt erst ermöglichen?

Edit:
Alter, verschachtelte If-Zweige und If-Ifelse-Zweige ohne Ende und keine einzige geschweifte Klammer und komischer Einrückung...sowas macht man doch mit Absicht. Warum soll man das nicht anmeckern?

 

[Robert Zenz]

Alter, verschachtelte If-Zweige und If-Ifelse-Zweige ohne Ende und keine einzige geschweifte Klammer und komischer Einrückung...sowas macht man doch mit Absicht. Warum soll man das nicht anmeckern?

Jetzt beruhig dich mal. Wenn man davon ausgeht dass der Code von Studenten geschrieben wurde, ist er schon in Ordnung. Gibt halt, wie bei den Meisten auch, Potential nach oben. Und das war ja auch nicht Sinn der Uebung (auch wenn ich etwas am Sinn der Uebung zweifeln muss, um ehrlich zu sein, weil mir noch zwei oder mehr Probleme aufgefallen sind welche zu beachten sind).

 

[Robert Zenz]

@JavaBeans Also, falls der Code nicht unmittelbar Absicht war, ich kann euch gerne eine komplette Review machen und euch erklaeren wo es welche Probleme gibt und was man verbessern kann, wenn euch das interessiert. Weil, wie ich in meinem Kommentar im Anschluss geschrieben habe, ein paar von den Sachen haben dann ziemlich abgelenkt von der eigentlichen Fragestellung die ihr hattet.

 

[White_Fox]

Jetzt beruhig dich mal.

Wieso...reg ich mich auf? Hier ist jedenfalls alles gut.

 

[kneitzel]

Naja - ich habe mir nur das erste Teil angesehen - aber ich bin mit nicht sicher, was da erwartet wird. Man soll das alte mit dem neuen vergleichen. Beim alten gibt es keine Implementation (Security Issue - wenn die Implementation fehlt, dann wirft man eine NotImplementedException!) Und dann wird einem sonst was unleserliches vorgesetzt. Alles was man bewerten könnte, soll man entweder nicht bewerten oder man soll davon ausgehen, dass es ok ist oder es gibt keine Information dazu:
-> Der Code selbst ist ja nicht zu bewerten.
-> Tests sind alle ok - somit muss man bei der Funktionalität nichts prüfen.
-> Tests selbst kennen wird nicht - daher müssen wir davon ausgehen, dass diese vollständig sind.

Was bitte soll man dann noch bewerten?

Offensichtliche Probleme ggf.? Sowas wie: registerUser enthält einen salt, der mit in der Datenbank gespeichert wird. Die generateHash() nutzt aber immer einen neu erzeigten SALT, der nicht gemerkt wird? Aber nein - das ist ja wieder Funktion -> Die Unit Tests werden doch hoffentlich das Speichern der Passworts (als Hash) und den Passwort-Check abdecken....

Also ok, bleibt das "Hurra - es wurde ein prepared Statement verwendet!"

Und dann schaut man sich die Fragen an:

"Are minimum and maximum password lengths enforced?"
Ja, soll ich nun davon ausgehen, dass die Tests erfolgreich waren oder nicht? Das sind doch alles Dinge, für die hoffentlich Unit Tests existieren. Und die Funktionalität soll doch sicher gestellt sein!

"Is sensitive data logged in a masked, sanitized, hashed, or encrypted state?"
Ja, zum Glück muss man nur ein einziges Log-Statement betrachten. Was wird jetzt getestet? Ob ich weiss, ob PreparedStatement::toString() übergebene Parameter mit ausgibt oder nicht?

"Is the set of allowed characters for passwords limited?"
Hmm ... Was soll ich da antworten? Natürlich ist es limitiert ... ein char hat nur 16 Bit ... mehr kriegt man da nicht rein. Und das UTF-16 Charset nimmt maximal 2 16 Bit Zahlen ... Also ja - das ist eine deutliche Limitierung.
Ja, sorry - die Frage soll natürlich darauf hinaus, ob man Reguläre Exceptions verstanden hat ... was macht so ein (?=.*[Zeichen]).* nur...

Also ich denke, dass es verständlich ist, wenn ich dies nicht weiter anschauen werde ...

 

[LimDul]

Ich hab es weiter angeschaut und finde das ganze extrem bescheiden. Ich hab nämlich nach dem lesen der Checklist und dem Code gedacht "Was für ein Bullshit" und einfach mal weitergeklickt und mir gedacht "Den Unfug fülle ich nicht aus"
Ergebnis - da war bewusst ein Haufen Unfug auf der Liste. Ob das jetzt das Ergebnis verfälscht oder nicht, weiß ich nicht, ich kam mir persönlich bei der Checklist vs. Code verarscht vor.

 

[JavaBeans]

Hallo allesamt. Vielen herzlichen Dank für Eure Zeit und Euer Feedback. Korrekt, ich bin Student, wollte euch auf keinen Fall mit dem Experiment verarschen. Ich untersuche spezifische Variablen im Experiment, deshalb wird ja einführend auch darauf hingewiesen, dass der Schwerpunkt auf "Sicherheitsaspekten" und nicht auf Code Design und Maintainability liegt. Falls Ihr die Möglichkeit habt das Experiment im Netzwerk weiterzuteilen wäre ich natürlich unendlich dankbar, da ich mein kritisches n im Experiment noch nicht erreicht habe. Einen schönen Abend allerseits!