Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichnis

Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichnis

Postby deramon » 30.03.2015, 13:33

Hallo,

im Zuge der Neuinstallation wsusoffline954.zip ist mir aufgefallen, dass auf den Clients die Überprüfung der Updates fehlschlägt, da die Hash-Dateien im md-Verzeichis die relative Pfadangabe
Code: Select all
..\client\...
enthalten. Wird der Parameter /verify oder die GUI zum Updates genutzt (dort ist Verify per default aktiv), schlägt das Update fehl, da z.B.
Code: Select all
..\wle\...
und nicht
Code: Select all
..\client\wle\...
erwartet wird.

Ich habe mir die Download-Datei dann man angesehen und festgestellt, dass von der Revision r634 auf r635 dieser Bereich umgestellt wurde. Dafür wird es sicherlich Gründe gegeben haben, aber die Pfadangaben in der Hash-Datei müssen dann angepasst werden...
Entweder es wird mühsam von Hand alles umgestellt, wie z.B. hier für Dotnet erklärt:
http://forums.wsusoffline.net/viewtopic.php?f=9&t=4790#p15252
oder einmal am Ende des Scripts der Pfad für alle Hash-Dateien angepasst:

Code: Select all
diff DownloadUpdates.sh DownloadUpdates.sh.r658

920c920
<     for Datei in ../client/${Vz}/*.exe
---
>     for Datei in ${Vz}/*.exe
1015,1017d1014
<
< # remove \client from hash-files:
< sed -i 's/client\\//g' ../client/md/*.txt


Tritt der Fehler auch bei euch auf, bzw. hilft der Patch euch?

Grüße und danke für das tolle Programm,

Ralf
deramon
 

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby hbuhrmester » 31.03.2015, 08:35

Hallo,

nach der Diskussion im Thread "dotnet entfernen schlägt fehl" hatte ich so ein Ergebnis schon befürchtet.

Für die Installation werden nur die Inhalte des client-Verzeichnisses benötigt. Wenn man nach dem Download ein ISO-Image erstellen lässt, werden nur die Inhalte des client-Verzeichnisses in die Imagedatei kopiert. Wenn man das Image auf eine DVD brennt, liegt die Datei wsusoffline/client/Autorun.inf im Rootverzeichnis der DVD, wie bei allen Installations-DVDs. Das heißt, ein Verzeichnis "client" gibt es dann gar nicht mehr! Deshalb sollte es in den Pfadangaben auch nicht auftreten.

Die Updates werden mit dem Skript wsusoffline/cmd/DownloadUpdates.cmd oder wsusoffline/sh/DownloadUpdates.sh heruntergeladen. Installiert werden sie mit dem Skript wsusoffline/client/cmd/DoUpdate.cmd. Dann ist wsusoffline/client/cmd das aktuelle Arbeitsverzeichnis, und alle relativen Pfadangaben müssen sich auf dieses Basisverzeichnis beziehen. Ein Verzeichnis auf derselben Ebene funktioniert genauso: Beim Erstellen der Prüfsummen kann man statt wsusoffline/client/cmd auch wsusoffline/client/md als Basisverzeichnis verwenden. Die relativen Pfade bleiben dann dieselben.

Es gibt sicherlich Möglichkeiten, die Dateien hinterher zu reparieren, indem man das Element "\client" aus den Pfadangaben löscht, aber eigentlich sollte das schon beim Erstellen der Prüfsummendateien richtig gemacht werden.



Im Grunde genommen aber taucht hier die grundsätzliche Frage auf, ob man der Integritäts-Datenbank überhaupt trauen darf, oder ob man sie nicht einfach ganz weglassen sollte. Denn die Integrität der heruntergeladenen Dateien sollte immer anhand einer externen Referenz überprüft werden. Das Windows-Skript macht das, indem die eingebetteten Dateisignaturen mit Sysinternals sigcheck.exe überprüft werden. Alle Downloads von Microsoft sind digital signiert, und unsignierte Dateien werden bei dieser Überprüfung wieder gelöscht. Erst danach werden mit hashdeep die Prüfsummendateien für die Integritätsdatenbank erstellt.

Beim Linux-Skript fehlt diese externe Referenz. Beim Download kann aber alles Mögliche passieren: vielleicht wird der Download unterbrochen und die Dateien sind unvollständig. Dann gibt wget hoffentlich eine entsprechende Fehlermeldung aus. Aber am Ende wird trotzdem eine Prüfsummendatei erstellt, und diese dient wiederum als Referenz für die Integrität der Daten? Das klingt so, als ob etwas Entscheidendes fehlen würde.

Eine externe Überprüfung ist in Linux allerdings auch schwer zu implementieren. Wahrscheinlich muss man ebenfalls Sysinternals sigcheck.exe nehmen und unter wine laufen lassen.

Mit dem Mono-Framework werden unter Linux einige Sicherheitstools installiert, die so ähnlich funktionieren wie die entsprechenden Tools von Microsoft, allerdings mit Einschränkungen: Mit chktrust aus dem Mono-Framework können nur ausführbare Dateien (PE executable) überprüft werden, keine Cabinet-Dateien. Aber auch die Überprüfung von ausführbaren Dateien schlägt fehl, wenn die entsprechenden Zertifikate nicht installiert sind. Diese müssen erst von Windows importiert werden.

https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
http://www.mono-project.com/docs/tools+libraries/tools/
https://developer.mozilla.org/en-US/doc ... thenticode

Viele Grüße,
Hartmut
hbuhrmester
 
Posts: 525
Joined: 11.10.2013, 20:59

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby DanielEckl » 13.07.2015, 14:39

Hallo zusammen,

das Problem hier scheint wohl irgendwie aus dem Fokus gerutscht zu sein, daher nehmt es mir bitte nicht übel, wenn ich das jetzt ein wenig pushe.

Fakt ist, dass SVN Commit r635 die Integritatsdatenbank beim Download unter Linux zerschießt. Und das grandios über alle Architekturen und Sprachen. Also jeder, der das unter Linux einsetzt, ist betroffen und der Installer, der per Default ja Verifikation aktiviert hat, stirbt mit einem "Audit failed". Ich kann nur befürchten, dass jeder, der das Problem hat, die Verifizierung einfach abschaltet, sonst fällt mir nicht ein, warum so wenige das Problem reporten.

Unabhängig von der Grundsatzfrage, wie vertrauenswürdig die unter Linux verfügbare Verifizierungsart ist, sollte es aber nicht sein, dass ein Feature, das Default an ist und beim Test im Happy Path nach Sekunden ins Auge fällt, einfach defekt ist und bleibt. Und wir reden von 7 Monaten und 5 Releases seit Einbau des Fehlers.

Die Idee, die vielen Verzeichniswechsel zu vermeiden und stattdessen die relativen Pfade zu korrigieren war ja nett gedacht, aber wie ihr ja schon erkannt habt, reagiert hashdeep genau wie tar, zip, md5sum und hundert andere Programme mit einem veränderten Ergebnis darauf. Und etwas bewußt falsch zu erstellen und dann am Ende per sed zu reparieren halte ich vom Prinzip her für den falschen Ansatz. Vielleicht gibt es eine andere elegante Lösung, um die Verzeichnissprünge zu vermeiden, aber diese ist es halt nicht, da beißt die Maus keinen Faden ab. Als erstes also wiederherstellen der alten Funktionalität, dann nochmal in Ruhe drauf rum denken.

Ich hoffe daher, dass jemand wie Helmut Hullen hier meinen Patch reviewen und dann mergen kann, ich hab nämlich sehr wenig Lust, über die ganzen Releases ein Patchset mit zu ziehen und zu pflegen, und auch keine Lust, anderen zu erklären, dass die Verifikation unter Linux irrelevant wäre und bedenkenlos abgeschaltet werden kann. Ich erziehe User zu mehr Sicherheit, nicht zu weniger, und gerade beim Thema Updates will ich ihnen nicht Schludrigkeit beibringen. Mein Patch ist unified und gegen die Version 9.7 und ist unter w61-64 enu getestet. Leider habe ich keine Dateiendung gefunden, die der Dateiupload hier akzeptiert, patch, diff, txt, zip, gz, alles angelehnt. Daher leider nur als Pastebin Link:

http://pastebin.com/uhqS1ivY

Ob man die Verifikation unter Linux nun entfernen will oder es dennoch einen kleinen Mehrwert bietet, das ist eine andere Diskussion, die ich an dieser Stelle nicht starten oder führen will. Ich will erst den Status Quo wieder herstellen.

Vielen Dank und viele Grüße aus Karlsruhe,
Daniel
DanielEckl
 

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby hhullen » 22.07.2015, 13:37

deramon wrote:Hallo,

im Zuge der Neuinstallation wsusoffline954.zip ist mir aufgefallen, dass auf den Clients die Überprüfung der Updates fehlschlägt, da die Hash-Dateien im md-Verzeichis die relative Pfadangabe
Code: Select all
..\client\...
enthalten. Wird der Parameter /verify oder die GUI zum Updates genutzt (dort ist Verify per default aktiv), schlägt das Update fehl, da z.B.
Code: Select all
..\wle\...
und nicht
Code: Select all
..\client\wle\...
erwartet wird.

[...]

Ralf


Ich habe das Prinzip der Änderungen jetzt (endlich) eingebaut; sorry für die lange Wartezeit.

Meine Variante, jeweils nach
Code: Select all
echo "Creating ..."
    (cd ../client/md; hashdeep ...)


Das erspart die ausführliche Formulierung der Hin- und Herturnerei durch die Verzeichnisse.
Eigentlich sollte so etwas in eine eigenständige Funktion gepackt werden, aber der Aufruf hat Varianten - leider.
Viele Grüsse
Helmut
hhullen
 
Posts: 100
Joined: 23.04.2012, 10:43

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby DanielEckl » 28.07.2015, 15:50

hhullen wrote:Ich habe das Prinzip der Änderungen jetzt (endlich) eingebaut; sorry für die lange Wartezeit.


Herzlichen Dank für die Flucht nach vorne! :D
DanielEckl
 

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby hhullen » 31.07.2015, 12:09

DanielEckl wrote:
hhullen wrote:Ich habe das Prinzip der Änderungen jetzt (endlich) eingebaut; sorry für die lange Wartezeit.


Herzlichen Dank für die Flucht nach vorne! :D


"Steter Tropfen höhlt den Stein" - die Änderungen sind jetzt abrufbar:
http://trac.wsusoffline.net/browser/trunk/sh

Vielen Dank mal wieder an Torsten! Und an die Vorredner, die sowohl den Fehlerort gefunden und genannt haben als auch Korrekturen vorgeschlagen haben.
Viele Grüsse
Helmut
hhullen
 
Posts: 100
Joined: 23.04.2012, 10:43

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby unwichtich » 02.09.2015, 07:19

Leider scheint es diese Änderung nicht in den Download "Most recent version, 20.08.2015 Version 10.0" geschafft zu haben, jedenfalls sind alle Pfade in den client/hashes-*.txt falsch. Die Dateinamen beginnen alle mit '..', aber dann folgt weder ein slash noch ein relativer Pfadname.

Nach dem Austausch der DownloadUpdates.sh durch die im voranstehenden Beitrag referenzierte:
http://trac.wsusoffline.net/browser/trunk/sh

sehen die Pfade/Dateinamen vernünftig aus ...
unwichtich
 

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby aker » 02.09.2015, 09:03

Das hängt vermutlich damit zusammen, dass wsusou 10.0 der trunk-Revision 684 entspricht und die neuste Revision im Trac die Revision 685 ist. Sie werden im nächsten Release enthalten sein (Version 10.0.1 oder 10.1).

Viele Grüße
Wer Rechtschreibfehler findet, darf sie behalten oder an den Meistbietenden versteigern. / Everybody finding a misspelling is allowed to keep or sell it.
aker

WSUS Offline Update „Community Edition“
https://gitlab.com/wsusoffline/wsusoffline/-/releases
aker
 
Posts: 3999
Joined: 02.03.2011, 15:32

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby WSUSUpdateAdmin » 03.09.2015, 13:40

So ist es. :)
GT
WSUSUpdateAdmin
Administrator
 
Posts: 2245
Joined: 07.07.2009, 14:38

Re: Verify-Fehler wegen Falscher Pfadangaben im MD-Verzeichn

Postby hbuhrmester » 07.09.2015, 08:52

Die Änderungen aus der Version 9.8 sind auch in der Version 10.0 enthalten. Allerdings sind dafür neue Probleme hinzugekommen:

Code: Select all
# Zeilenumbruch passend für DOS/Windows
(cd ../client/md
# Unix2Dos fuer Arme - Dank an Norbert Möndjen
for Datei in hashes*.txt
  do
    grep -q -m1 $'\r' $Datei && continue
    while read Zeile
      do
#      sed 's/$/\r/' $Zeile
       echo -e "${Zeile}\r"
      done < $Datei > ${Datei}.tmp
    mv -f ${Datei}.tmp ${Datei}
  done
)


Ein Backslash dient in DOS-Skripten einfach als Pfadtrennzeichen.

In einer Linux-Shell und in vielen anderen Linux-Befehlen dient ein Backslash als Escape-Zeichen, um zum Beispiel ein Anführungszeichen oder einen Zeilenumbruch zu maskieren. Viele Steuerzeichen werden in Linux ebenfalls mit einem Backslash eingeleitet. Die Shell und die meisten Kommandos interpretieren Escape-Zeichen in der Regel automatisch; man muss zusätzliche Optionen angeben, um das zu verhindern.

Problemfall read

read verändert die Zeile beim Lesen: Leerzeichen am Anfang und Ende werden gelöscht, und Escape-Zeichen werden interpretiert. Die meisten Escape-Sequenzen haben hier keine besondere Bedeutung; das Ergebnis ist aber, dass alle Backslashe beim Lesen gelöscht werden.

Deshalb sollte man fast immer die Option -r verwenden, wie in http://mywiki.wooledge.org/BashFAQ/001 vorgeschlagen wird:

The read command modifies each line read; by default it removes all leading and trailing whitespace characters (spaces and tabs, if present in IFS). If that is not desired, the IFS variable has to be cleared:

# Exact lines, no trimming
while IFS= read -r line; do
printf '%s\n' "$line"
done < "$file"

The -r option to read prevents backslash interpretation (usually used as a backslash newline pair, to continue over multiple lines or to escape the delimiters). Without this option, any unescaped backslashes in the input will be discarded. You should almost always use the -r option with read.

http://mywiki.wooledge.org/BashFAQ/001


Problemfall echo

echo -e interpretiert ebenfalls Escape-Sequenzen, wobei die Shell eine Reihe von Steuerbefehlen kennt. Deshalb kann man "\r" für einen Carriage Return angeben. Aber dann gilt diese Übersetzung eben auch an allen anderen Stellen, und eine Reihe anderer Steuersequenzen wird ebenfalls interpretiert.

Das Bash-Manual schreibt über den eingebauten Befehl "echo":

Code: Select all
echo [-neE] [arg ...]
  Output the args, separated by spaces,  followed  by  a  newline.
  The return status is always 0.  If -n is specified, the trailing
  newline is suppressed.  If the -e option is  given,  interpreta‐
  tion  of  the following backslash-escaped characters is enabled.
  The -E option disables the interpretation of these escape  char‐
  acters,  even  on systems where they are interpreted by default.
  The xpg_echo shell option may be used to  dynamically  determine
  whether  or not echo expands these escape characters by default.
  echo does not interpret -- to mean the  end  of  options.   echo
  interprets the following escape sequences:
  \a     alert (bell)
  \b     backspace
  \c     suppress further output
  \e
  \E     an escape character
  \f     form feed
  \n     new line
  \r     carriage return
  \t     horizontal tab
  \v     vertical tab
  \\     backslash
  \0nnn  the  eight-bit  character  whose value is the octal value
         nnn (zero to three octal digits)
  \xHH   the eight-bit character whose value  is  the  hexadecimal
         value HH (one or two hex digits)
  \uHHHH the  Unicode (ISO/IEC 10646) character whose value is the
         hexadecimal value HHHH (one to four hex digits)
  \UHHHHHHHH
         the Unicode (ISO/IEC 10646) character whose value is  the
         hexadecimal value HHHHHHHH (one to eight hex digits)


Mit "\c" wird also der Rest der Zeile abgeschnitten. Deshalb wird der Pfad "..\client\md" zu ".." verkürzt.

Das Verhalten von echo ist nicht wirklich standardisiert. In der bash und im externen Befehl /bin/echo werden Steuersequenzen nur interpretiert, wenn man die Option -e verwendet. In der bash kann man auch die Shell-Option xpg_echo setzen, um das Verhalten umzukehren.

In der dash werden Steuersequenzen immer interpretiert, die Optionen -e und -E gibt es anscheinend nicht.

Da gerade auch die dash als kleine und schnelle Shell für Shell-Skripte verwendet wird, heißt es, dass man echo -e niemals verwenden soll.

Einfache Meldungen funktionieren auch ohne diese Option, und für schwierigere Fälle kann man printf verwenden, wie im oberen Beispiel angegeben.

Basically, never use options to echo, and for portability, use printf.

-- https://stackoverflow.com/questions/115 ... ing-printf


Eine andere Lösung zum Ändern der Zeilenenden, die auch getestet ist:

Code: Select all
function convert_to_dos ()
{
    local pathname=""
    local line=""

    echo "Converting checksum files to DOS line endings..."

    grep --files-without-match $'\r' --recursive ../client/md |
    while read pathname
    do
        echo "${pathname}"
        while IFS= read -r line
        do
            printf '%s\r\n' "$line"
        done < "${pathname}" > "${pathname}.tmp"
        mv "${pathname}.tmp" "${pathname}"
    done

    echo "Done."
}

convert_to_dos
hbuhrmester
 
Posts: 525
Joined: 11.10.2013, 20:59

Next

Return to Linux

Who is online

Users browsing this forum: No registered users and 46 guests