Über den Nutzen geschweifter Klammern bei bedingten statements

24/02/2014 - 09:21 von Georg Bauhaus | Report spam
Auszug aus http://opensource.apple.com/source/...Exchange.c:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
...

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
...
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;

}


Die Folge soll eine Sicherheitslücke sein, die Datenkommunikation
im selben WLAN mitlesbar macht. Interessanterweise ist an vergleichbaren
Stellen eine Leerzeile zu sehen. Hàtte hier ein verbessertes release
management etwas àndern können, sofern es damit zu tun hat?
(Im neulich diskutierten Beispiel von Hellmut Schellong war so etwas als
mögliche Ursache ins Gespràch gebracht worden.)
 

Lesen sie die antworten

#1 ram
24/02/2014 - 12:37 | Warnen spam
Georg Bauhaus writes:
Die Folge soll eine Sicherheitslücke sein, die Datenkommunikation



Ich weiß ja nun gar nicht, was überhaupt der Fehler war.

Ich sehe zwar das unbedingte Goto, aber ich kann ja nicht wissen,
ob das richtig oder falsch ist. Dahinter ist unerreichbarer Code,
aber das könnte ja so richtig sein. Unerreichbarer Code ist zwar
erklàrungsbedürftig, aber sein Vorhandensein ist nicht unbedingt
immer ein Fehler. Ob die Semantik der Funktion richtig ist, kann
ich mangels Kenntnis ihrer Anforderungsspezifikation ja nicht wissen.

In Java bricht der Compiler das Programm mit einer Fehlermeldung
ab, falls er erkennt, daß bestimmte Code-Teile nicht erreichbar sind.

Ich kann leider UTF-8 im Subject nicht lesen. Aus Sicherheitsgründen
möchte ich keine Subject-Zeile verwenden, von der ich gar nicht weiß,
wie sie lautet. Daher mußte ich die Subject-Zeile leider àndern.

Ähnliche fragen