blackarch / blackarch-guide Goto Github PK

if you look in source, then nothing's missing. if you look in pdf, then ...

In the French translation file, missing fragment of the overview

\chapter{Introduction}

\section{Qu'est-ce que BlackArch Linux?}
\href{http://www.blackarch.org}{BlackArch Linux} est une légère expansion d'Arch
Linux destinée aux professionnels de la sécurité informatique.
\\\\
L'ensemble d'outils est distribué tel un
\href{https://wiki.archlinux.org/index.php/Unofficial\_User\_Repositories}
{dépôt non-officiel} d'Arch Linux, vous permettant d'installer les composantes de
BlackArch sur une installation d'Arch Linux existante. Les paquets peuvent y être
installés individuellement ou par catégorie.
\\\\
Le dépot logiciel de Black Arch contient plus de 650 outils et ce nombre augmente
sans cesse. Tous ces outils sont minutieusement testés avant d'être ajouté aux
dépots, afin de garantir leurs bon fonctionnement.

%\section{The story of BlackArch Linux}
%foo bar

blackarch-guide/latex/blackarch-guide-fr.tex

Any reason you have several shell scripts for building. I would think it would be eaiser to stream this all with make?

Also any reason you don't have this hooked into TravisCI? Do you use some other CI pipeline?

I would be willing to handle the TravisCI and make stuff if you would accept the pr.

In the spirit of keeping things clean I would forgo the latex2html steps. I would just have the pdf load as a page. There are several reasons for this:

• easier to maintain the code
• much of the noise in the build output is related to the html2latex stuff
• pia hacks are needed to do this
• if someone wants an html version they can do it themselves, the source is available
• pdf renders better, is easier to read and in general you really don't want to generate html pages with tex.

I would decide on which format is most important. If the html is the primary and the pdf is the secondary then convert the whole mess to markdown and be done with it. You will find people will have a much easier time committing to the docs if they are in a more well known language. There are far better ways of generating documentation then LaTex unless you have an absolute need for it. (Jeykll, Middleman, Pandoc, Hugo, etc)

If the primary focus is indeed pdf (I think it should be) then stick with LaTex and drop the html pretense. Give them a pdf and save yourself the time of dealing with the html nonsense, you will thank yourself in the long run.

Hey there,
I am a graduate student, in Guangzhou University. My major is program&network security. I'm willing to translate guide to Chinese.
I wanna to know that, has anyone translated it to Chinese?

Hope to get your reply.

From Tao

This is one of the description of basic usage of Blackman. Shouldn't it be "To list category **of ** tools" or "To list tools category" ?

I am all for brand cohesion and I like the black/red/white but for documentation I think something more neutral should be adopted, at least in the pdf version after the title pages.

At some point as the guide grows it will get tough on the eyes to read it and also syntax highlighting would be nice in the proposed examples sections and that will look off with all the darkness.

Maybe some kind of neutral grey with black writing would be nice, it will still keep it looking not like a traditional book but will also be much eaiser on the eyes for prolonged reading.

current blackarch installs compile / fail if your python is 3.8 and not python3.7

running "sudo blackman -a" or "sudo blackman -g blackarch-forensics"
produced oodles of the same error message in regards to line 178 from /usr/lib/python3.8/site-packages file=sys.stderr

infact for each and every package it burped out that same error

yup my python was to new for the install...

in my case this was in my .bashrc file:

export PYTHONPATH=${PYTHONPATH}:"/usr/lib/python3.8/:/usr/lib/python3.8/site-packages/"

me being simple, comment out the line, duplicated the line as follows:

export PYTHONPATH=${PYTHONPATH}:"/usr/lib/python3.7/:/usr/lib/python3.7/site-packages/"

after opening new terminal and running the command to install again, all was well in the boxen verse.

as i'm new here and only complaining cuz i can, i though i would help out instead.

solution
insert one line somewhere near the top of the install guide / website mentioning the python version requirement

CS13337

1. Fork the repository from https://github.com/BlackArchLinux/blackarchlinux

There is no such repo. Shouldn't it be https://github.com/BlackArch/blackarch ?

It's writtent to write

sudo ./strap.sh

but it says command not found.

So instead, it should be:

sudo sh ./strap.sh

and it works :)

This is low priority that I hesitate to bring up, but this statement "The filesystem for each of those partitions must be defined. Ext4 is the default choice since it's the most recent." I can't decide whether it would be better to say "Ext4 is the default choice since it is the stable, well-tested successor to Ext3" or just delete "since it's the most recent". Btrfs, the default of SUSE linux, came out in 2007, a year after Ext4, in addition others. And, as well as not being accurate, it sounds really lame! Surely it's better to not say anything than give this out this poor excuse for providing it as the default.
I'll check back and I'm leaning toward deleting the short phrase because I hate to presume the reason when I have no knowledge of actual decision-making process. (or if there even was a decision as opposed to just doing whatever others have done with Arch, etc.)

There are several spots in the docs where you maintains lists of users, repos, etc. As the docs and the project grow this may become a challenge to maintain. These items should be or are already codified in various other places and can be brought in programmatically at build time.

I propose switching the builder from pdflatex to luatex and writing some automated scripts to pull in this data is a usable fashion. Some specific examples would be:

• a text file with a list of maintainers and contributors that could get read in at build time and looped over in the latex source
• a script to loop over the list of package groups and pull the description from them
• use gitinfo2 to add the revision tag to the document as a way to maintain the version of the source against what is built live

Raspberry Pi 4 (8gb)
Arch Linux (AArch64)

Following the steps as directed in the installation guide to install on top of an existing Arch installation.

This step

Enable multilib following https://wiki.archlinux.org/index.php/Official_repositories#Enabling_multilib and run:
$ sudo pacman -Syu

(side note there is no multilib entry to uncomment in /etc/pacman.conf)

results in an error stating

error: failed retrieving file 'multilib.db' from mirror.archlinuxarm.org : The requested URL returned error: 404

It would appear that the multilib package is unsupported in the aarch64 build(s)

The docs/TODO.md says the structure of the wiki is still to be discussed.
Here is what I have in my mind.

Referencing .md files ( or .md books, using https://github.com/rust-lang/mdBook ) sounds doable to me inasmuch as this would mean 1 'book' per tool.

Only this would also mean a lot of repetitions, both for cross category tools and for those of the same category, to explain the same things over again.

Not to mention this would create standalone books and would not constitute a wiki.

This creates the need for non-tool-specific 'books' that would tackle 'general' concepts, and can be linked-to from the tool-specific 'books'.

Finally, linking these together, would have much the same effect as a wiki referencing its own pages.

In much the same way that the ArchWiki is a reference for its clarity and effectiveness in explaining anything linux-related, so could the BlackArchWiki become a reference for all things hacking related.

Hello, I just read the Turkish translate of Black Arch and I compare with latex file and seems to be PDF didn't contain turkish special char such as (ş,ç,ğ,ü,i,I,ö) so It need to re-generate from Latex file.

Thank you

Link : https://blackarch.org/blackarch-guide-tr.pdf