On Wed, 2005-05-11 at 00:18 -0500, Thomas Jones wrote: > tuxxer wrote: > > <snip> > > I am not sure if peer review is sent to the mailing list or directly to > just the author. Some suggestions are questionable due to my > inexperience in precedence set by the editors and authors before me. So > the editors may have better ideas on the concepts. There may even be a > guide pertaining to such questions; if not, it may behoove us to > generate one. > > But here is a few technical suggestions for chapter #1 if you are still > in the market for them: > > Well most are technical -- a few may be preference. :P > > First let me state that you have done a very good job of generating > meaningful content. The complexity yet readability of the document is > very evident from my first review. Most items I comment on are > nit-picking and do not in anyway detract from the quality job you have > done! Hopefully you can find value in my recommendations so that you > can continue to author quality works such as this. > > Good job!!! :) > > 1.1.2.1:: > > 1) If I may, I would suggest utilizing the --lsign-key command rather > than --sign-key for various reasons. > > Unless you decide to introduce to the end-user a sufficient amount of > personal verification of the owner(s) of the key; you should not > "globally" sign the kernel.org public-key. > > If the end-user were to accidentally do the following: > gpg --send-keys > > Then ALL keys --- including the incorrectly signed key --- would be > exported to the default keyserver. This undermines the trust model used > by the specific public-key, and the gpg public-key cryptosystem itself. > > Instead a "local signature" is advised. This type of signature > introduces a "local" verification of the end-users trust level and thats > it. If the end-user executed the same command as above; the local > signature would not be exported. Hence, keeping the "global" integrity > of the kernel.org public-key intact. > > 2) This section, nor does the kernel.org hyperlink, discuss any > verification of the public-key that is being imported. > i.e. verifying the key fingerprint > > This step needs to be performed prior to signing it with the "Bogus > key". Otherwise, the end-user is blindly signing the imported > public-key. Which actually should be done prior to the actual > importation into the end-users recently generated keyring. Verify the > integrity of the public-key, than import it into the keyring. Finally, > perform the trust-level verifications as needed by the scenario at hand, > and sign the key to rid the end-user of that annoying trust warning. > > 3) Personal preference --- I would extract only the relevant data from > the output of "ftp ftp.kernel.org". Alot of the data is fluff, seems > irrelevant to the process at hand; and detracts from the good > step-by-step process description that you are providing. ;) > > 1.1.2.2:: > > 1) The output contained in the "ftp download.fedora.redhat.com" process > is similar to the above #3 comment. Some output seems irrelevant. > > 2) The md5sum process comprised of the last three(3) outputs can be > executed with a single sequence of commands: > > md5sum -c MD5SUM 2> /dev/null | grep 'FC3-i386-disc1.iso' > > with an output of: > > FC3-i386-disc1.iso: OK > > The redirection of stderr is necessary because multiple packages are > contained within the checksum file, however this is much simpler for the > end-user. Traversing back and forth from two 32 hexadecimal characters > sequences to verify authenticity is a tedious job. > > If later chapters include similar checks for individual packages; the > above command can be simplified to the following: > > md5sum -c package-1.0-fc3.md5 > > 3) If you decide not to use the above change #2; then the statement "If > the hexadecimal number in the first column matches the hexadecimal > number output..." should be changed to: > > "If the 32 digit hexadecimal character sequence in the first column > matches the 32 digit hexadecimal character sequence output..." > > This correctly identifies the process as not just containing numerical > digits. > > 1.2:: > > 1) Generally it is always recommended to utilize sudo rather than > directly changing to the EUID of 0; regardless of the number of commands > to be executed. This greatly reduces the chance(s) that an irrecoverable > accident can occur from utilizing superuser permissions. Given the > experience level of some of the end-user(s) of this document; it may be > advisable to change this statement accordingly. > > 2) The sentence "This file allows you to set up commands and aliases > that are allowed through sudo, and which users are allowed to run them." > should be altered to identify that you the end-user can also regulate > the authorized machine from which a particular user can execute a > specific command. > > 3) The document topic is about "hardening a fedora installation" but the > example output of /etc/sudoers utilizes the most insecure alias > available under the sudo system. I would definitely alter this to a more > restrictive example. > > 1.3:: This chapter is well done. Kudos --- Charles > > 1.4:: > 1) Alter the following sentence "Make sure that you have all of the > updates." to read "Make sure that you have all of the most current updates." > > The reasoning behind this is due to the capability of the end-user to > utilize "delta" rpms. > > With reference to "delta" meaning a calculated difference between two > specific versions of a package. > > By using this update scheme, the end-user can successfully update to the > most current version of a package without the need for any intermediary > patches for a given package. For example: > > Under normal update procedures, if a user has the following initial > release installed ---- package-1.0.12.fc3.rpm and wants to update to the > most current version package-1.0.15.fc3.rpm the end-user must download > ALL of the following ---- package-1.0.13.fc3.rpm, package-1.0.14.fc3.rpm > and package-1.0.15.fc3.rpm > > However, in a delta update system; the end-user must only download a > single update package. I noticed mailing list traffic pertaining to beta > deployments of delta fedora repositories being tested over the last > month. Other distributions utilize this scheme and would expect that in > the near future this will be the recommended update procedure. It may > even behoove the end-user to be aware of this capability regardless of > utilization stability within fedoras update repositories. > > This seems to be a preemptory change due to documentation of the > so-called "standard" installation. It may very well be considered for > future use; but I felt it needed to be addressed for possible inclusion. > > 2) Alter the sentence "This is indicated by the red exclamation point > icon in the upper right hand corner of the screen, on the panel." to the > following "This is indicated by the red exclamation point icon located > in the upper right hand corner of the Gnome panel." Seems to flow a > little better. > > 3) Personal preference --- Alter the sentence "Follow the instructions > in the follow on dialogs to update your system" to "Follow the > instructions in the subsequent dialogs presented to update your system". > > 1.5:: This chapter looks very good!!! Well done. ;) > > 1.6.1:: > > 1) This section does not notify the end-user of the "administrative > privileges" dialog that is presented. > > 2) The "upper-right pane" term is identified as actually being a "Text > View" in interface designing. What is the correct procedure for this? > Pane seems more descriptive, yet it is not the proper terminology. > > This goes for all gui items. i.e. check box --> check button > > ???????? > > 3) The important admonition statement "stopping that particular service > will inhibit any functionality you expect from the system" should be > altered to "stopping that particular service will inhibit any > functionality you do not expect from the system". > > 1.6.2:: > > 1) The note admonition seems redundant. In previous sections, changing > to an effective uid of 0 had already been reviewed. As well, the > previous sections utilizing the "sudo" command did not contain such a note. > > 2) The statement " If you are running in command line only mode > (runlevel 3)" incorrectly states available runlevels. Runlevels 1,2 and > 3 are all of the console persuasion. > > 1 - is single-user mode --- only root access from the local tty console. > No pseudo ttys. > 2 - is multi-user mode without networking --- various user logins > authorized from from the local console terminal. > 3 - is multi-user mode with networking --- various user logins > authorized from from the any console terminal. Local and pseudo included. > > Although, runlevels 1 and 2 are normally utilized for debugging and > administrative purposes only; it is still a resource that may be > utilized by the more experienced end-users. > > 3) There is reference to changing permissions of file in this section. > It would be a good idea to go over this topic. Otherwise, the > inexperienced end-user may inadvertently chmod this script to being > readable by the "other" user class ---- and god forbid executable as well. > > 4) Also there is an inconsistent transfer of uid's on this page. The > end-user starts out as the uid of a normal user ---- say 501; and is > transitioned to a uid of 0 with regards to execution of the generated > script. > > 5) The last statement incorrectly identifies only runlevels 3 and 5 as > multi-user runlevels. However, runlevel 2 is as well. > > 1.7:: > > 1) If I might suggest, place a warning in this section stating that the > end-user is recommended to make a backup of the /etc/passwd file and the > /etc/shadow files. > > Which if implemented, needs to also recommend the proper placement of > such a backup. As well as, any recommended cryptographic procedures to > secure the backup against compromise. > > i.e. encryption and digital signing of the backup using the new gpg > keyring. ;) > > 2) " Remember the list of services that you disabled." is a question. > > 1.7.1:: > > 1) The authorization tip admonition should identify the referenced > dialog box as "administrative privilege dialog box" or as the > "userhelper dialog box interface to PAM". Or something such as this. > What is the precedence of the fedora-docs team prior to this? Tom, Just a quick reply, thanks for all of your comments. You're more complementary than anyone so far! ;-) It's late for me, but I will provide a more detailed reply tomorrow. Thanks again for replying, I'm ready to get this edited and published. -Charlie -- -tuxxer echo "uvyyfsAdpy/ofu" | perl -pe 's/(.)/chr(ord($1) - 1)/ge' gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list
