Posted by Eriberto on set 18, 2016 in
Debian In the last week I played a bit with UDD (Ultimate Debian Database). After some experiments I did a script to generate a daily report about source packages in Debian. This report is useful to choose a package that needs help.
The daily report has six sections:
- Sources in Debian Sid (including orphan)
- Sources in Debian Sid (only Orphan, RFA or RFH)
- Top 200 sources in Debian Sid with outdated Standards-Version
- Top 200 sources in Debian Sid with NMUs
- Top 200 sources in Debian Sid with BUGs
- Top 200 sources in Debian Sid with RC BUGs
The first section has several important data about all source packages in Debian, ordered by last upload to Sid. It is very useful to see packages without revisions for a long time. Other interesting data about each package are Standards-Version, packaging format, number of NMUs, among others. Believe it or not, there are packages uploaded to Sid for the last time 2003! (seven packages)
With the report, you can choose a ideal package to do QA uploads, NMUs or to adopt.
Well, if you like to review packages, this report is for you: https://people.debian.org/~eriberto/eriberto_stats.html. Enjoy!
Tags:.deb, debhelper, Debian, empacotamento, NMU, packaging, pacote, QA, Sid, UDD, Ultimate Debian Database, unstable
Posted by Eriberto on ago 18, 2016 in
Debian,
Sistema Operacional Since GPG 2 was set as default for Debian (Sid, August 2016), an error message appeared inside jails triggered by chroot, when using debuild/debsign commands:
clearsign failed: Inappropriate ioctl for device
The problem is that GPG 2 uses a dialog window to ask for a passphrase. This dialog window needs a tty (from /dev/pts/ directory). To solve the problem, you can use the following command (inside the jail):
# mount devpts -t devpts /dev/pts
Alternatively, you can add to /etc/fstab file in jail:
devpts /dev/pts devpts defaults 0 0
and use the command:
# mount /dev/pts
Enjoy!
Tags:.deb, chroot, clearsign, Debian, debsign, debuild, devpts, empacotamento, GnuPG, GnuPG2, GPG, gpg2, ioctl, packaging, pacote, tty
Posted by Eriberto on set 7, 2015 in
Debian Implementing the hardening
When packaging in Debian, is very common to see the lintian messages 'hardening-no-relro' and 'hardening-no-fortify-functions' in some softwares written in C or C++. To solve these issues, we can use the 'blhc' tool (apt-get install blhc).
Please, get the revision 1.11-9 of the icmpinfo package. You can get this revision from http://snapshot.debian.org or from http://eriberto.pro.br/debian/icmpinfo. As a shortcut, you can use the following command:
$ dget -u http://eriberto.pro.br/debian/icmpinfo/icmpinfo_1.11-9.dsc
The icmpinfo 1.11-9 is almost clean for lintian (in 2015-09-07, Standards-Version 3.9.6). The only problem is:
W: icmpinfo: hardening-no-relro usr/sbin/icmpinfo
To track the problem I will use blhc over the .build file:
$ blhc icmpinfo_1.11-9_amd64.build
LDFLAGS missing (-Wl,-z,relro): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -o icmpinfo recvping.o print.o err.o icmpinfo.o pid.o
Note that the problem is some missing options (-Wl,-z,relro) for LDFLAGS when building icmpinfo (for newbies, in GCC, -o is used to indicate the name to be used for the final binary after the compilation). If you are using the DebHelper compat 9 (debian/compat=9) and the DebHelper 9 (debhelper >= 9 in Build-Depends field in d/control), some variables as CFLAGS, LDFLAGS, CPPFLAGS and CXXFLAGS will be automatically passed during calls to dh_auto_* programs (yes, you should use the new and reduced d/rules format - see as example the debian/rules of the icmpinfo 1.11-9; if you still have doubts, $ man dh).
Now, we need discover the reason why the LDFLAGS is being changed between its generation by the Debian build system and its utilization by the upstream's source code. So, we need to check the upstream Makefile.
There is in Makefile (after a 'quilt push -a', to apply all current patches):
LDFLAGS= $(CFLAGS)
OBJECTS= recvping.o print.o err.o icmpinfo.o pid.o
TARGET = icmpinfo
$(TARGET): $(OBJECTS)
$(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
Hummm... The LDFLAGS content generated by Debian is being dropped by Makefile because it is saying that "LDFLAGS = CFLAGS content". This line is a problem because the upstream Makefile needs to take and use the CFLAGS and LDFLAGS independently. To fix the issue, you can use this patch:
--- icmpinfo-1.11.orig/Makefile
+++ icmpinfo-1.11/Makefile
@@ -20,13 +20,13 @@ VERS = 1.11
RM = rm -f
-LDFLAGS= $(CFLAGS)
+#LDFLAGS= $(CFLAGS)
OBJECTS= recvping.o print.o err.o icmpinfo.o pid.o
TARGET = icmpinfo
$(TARGET): $(OBJECTS)
- $(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
+ $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
tgz: clean
rm -f CHECKSUMS.asc
After a 'debuild' is a fact the problem is solved and the lintian is happy. See the blhc results:
$ blhc ../icmpinfo_1.11-9_amd64.build
$
Now, we can improve the hardening. To see the current status, we can use the 'blhc --all' command. See here:
blhc --all ../icmpinfo_1.11-9_amd64.build
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o recvping.o recvping.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o print.o print.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o err.o err.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o icmpinfo.o icmpinfo.c
CFLAGS missing (-fPIE): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -c -o pid.o pid.c
LDFLAGS missing (-fPIE -pie -Wl,-z,now): cc -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -o icmpinfo recvping.o print.o err.o icmpinfo.o pid.o
Well, we know that CFLAGS and LDFLAGS are present. Now, we can force the DebHelper to pass some extra options to make hardening better. Generally, is only needed to add the following line to debian/rules:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
See the results (after a new debuild command):
$ blhc --all ../icmpinfo_1.11-9_amd64.build
$
More examples
Let me to show other example. I will use the mac-robber 1.02-3 (however, I disabled the Makefile.patch in debian/patches/series). After a debuild, the following lintian messages are presented:
W: mac-robber: hardening-no-relro usr/bin/mac-robber
I: mac-robber: hardening-no-fortify-functions usr/bin/mac-robber
Using blhc:
$ blhc ../mac-robber_1.02-3_amd64.build
CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat -Werror=format-security): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
CPPFLAGS missing (-D_FORTIFY_SOURCE=2): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
LDFLAGS missing (-Wl,-z,relro): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
We need to verify what is the problem in Makefile with CFLAGS, CPPFLAGS and LDFLAGS when generating the binary 'mac-robber' (just recalling, -o mac-robber in GCC command). See:
linux_notstatic:
$(CC) -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
There are no references to CFLAGS, CPPFLAGS and LDFLAGS. To solve the problem, we need patch the Makefile to make this:
linux_notstatic:
$(CC) $(CFLAGS) $(LDFLAGS) $(CPPFLAGS) -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
As last example, is possible that the Makefile is overriding the content sent by DebHelper when building. See this line from a hypothetical Makefile:
CFLAGS = -g -Wall
As you can see, the Makefile is redefining CFLAGS; consequently, it is discarding any previous content sent by DebHelper. To solve this issue, we can use the following patch:
-CFLAGS = -g -Wall
+CFLAGS += -g -Wall
So, the content received from DebHelper will be added to '-g -Wall'.
Default parameters
As curiosity, to see the basic parameters created by DebHelper as hardening, use the command:
$ dpkg-buildflags
To see the all parameters, use the command:
$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags
More information
More information about the hardening can be viewed at two places:
https://wiki.debian.org/Hardening
https://wiki.debian.org/HardeningWalkthrough
I hope this help. Enjoy!
Tags:blhc, CFLAGS, CPPFLAGS, debhelper, Debian, dpkg, empacotamento, G++, GCC, hardening, hardening-no-fortify-functions, hardening-no-relro, LDFLAGS, Linux, packaging, pacote
Posted by Eriberto on maio 2, 2015 in
Debian Today, trying upload to jessie-backports from a Jessie jail, I got this message from dput-ng:
$ dput netdiscover_0.3beta7~pre-2~bpo8+1_amd64.changes
Uploading netdiscover using ftp to ftp-master (host: ftp.upload.debian.org; directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to the target distribution
`jessie-backports' not in the codename group
To solve this problem, you can edit the /usr/share/dput-ng/codenames/debian.json file and add jessie-backports here:
"backport": [
"stable-backports",
"oldstable-backports",
"jessie-backports",
"wheezy-backports",
"squeeze-backports"
],
I hope this help someone.
Tags:backports, Debian, empacotamento, Jessie
Posted by Eriberto on jun 7, 2014 in
Internet,
Rede,
Segurança O SSL inspection é uma técnica de firewall, criada há poucos anos, utilizada para verificar o conteúdo de tráfego de rede criptografado.
Em uma conexão criptografada, apenas o usuário envolvido e o servidor de rede final conseguem visualizar o conteúdo do tráfego. Esse é o fator que propicia a segurança desejada pelo usuário ao acessar sites que requeiram a utilização de dados pessoais ou a visualização de informações sigilosas. Um exemplo é o acesso a um sistema de Internet banking, onde o usuário disponibiliza sua senha pessoal e acessa dados pessoais e sigilosos. Outra situação correlata é uma compra pela Internet, na qual todos os dados de cartão de crédito serão digitados. Esses são casos clássicos de utilização de criptografia na conexão para proteger os usuários. No acesso via página, por exemplo, quando se quer segurança, é utilizado o protocolo HTTPS em vez de HTTP. O “S” se refere a “secure”. Em resumo, o uso de criptografia provê segurança ao usuário; no entanto, isso cega o sistema de firewall, fato que ocorre, naturalmente, em todas as redes em prol da segurança pessoal de quem as utiliza.
A técnica de SSL inspection foi desenvolvida para uso em casos específicos, pois da mesma forma que uma conexão criptografada pode ser utilizada em prol da segurança dos usuários, ela também pode ser empregada para o tráfego de arquivos maliciosos, que afetariam sistemas externos à instituição que detém o firewall. Assim, tal instituição poderá, em casos específicos e mais raros, adotar o SSL inspection para verificar determinadas conexões, oriundas de uma máquina da rede suspeita de ações incompatíveis. Para tanto, com o SSL inspection, o administrador da rede poderá “quebrar” a criptografia entre o usuário e o servidor de destino e analisar tudo que estiver trafegando entre os dois.
Vários sistemas de firewall comerciais modernos disponibilizam a técnica de SSL inspection. No entanto, o uso indiscriminado de tal técnica consiste em violação de privacidade, configurando crime, de acordo com a lei do país onde ocorra e que trate tal assunto como irregular. Geralmente, o uso do SSL inspection está vinculado a determinações judiciais ou testes em ambientes de pesquisa de malwares, como empresas de produção de antivírus. É necessário lembrar que existem alguns entendimentos errôneos sobre o que se pode ou não fazer dentro de uma empresa. Um desses entendimentos criou uma “lenda” que diz que “tudo o que circula dentro de uma empresa pertence à mesma”. No entanto, a lei, geralmente, aplica ao mundo virtual o mesmo que aplica ao mundo real, uma vez que o virtual sempre segue o que o real pratica. Em outras palavras, tudo no mundo virtual é feito da mesma forma como ocorre no mundo real. Então, no caso de um telefone funcional, provido a um empregado da empresa, poderia tal empresa grampear o aparelho e escutar todas as conversas telefônicas? É sabido que não. Então, dentro da mesma analogia, ninguém pode praticar SSL inspection sem prévia e competente autorização, ou seja, uma ordem judicial. Uma exceção conhecida é a dos e-mails corporativos, desde que haja uma cláusula expressa nos contratos de trabalho, informando que tal e-mail não deverá ser utilizado para fins pessoais e que poderá ser monitorado. Mesmo assim, há diversos casos na história jurídica de monitoramentos inadequados e por motivos irrelevantes, que geraram decisões a favor de empregados de empresas em processos judiciais. É algo análogo a um policial que, sem motivo, algema uma pessoa na rua porque ela possui braços e pode cometer um crime. Assim, uma empresa que monitore o e-mail funcional de um empregado sem um motivo aparente, poderá ser processada pelo mesmo e perder a causa, vindo a ter que indenizá-lo.
Em uma conexão criptografada é utilizado um certificado digital instalado no servidor de rede que contém os dados a serem protegidos durante a sessão. Esse certificado deverá ser homologado por uma autoridade certificadora, como Verisign[1], Certsign[2] ou a ICP-Brasil[3], que é reconhecida por todos os navegadores de páginas e, em consequência, tem poder para atestar a veracidade do servidor e o sigilo da comunicação. No caso do SSL inspection, o certificado da autoridade certificadora é trocado por um certificado do firewall durante o tráfego, e com isso, como uma espécie de “grampo telefônico”, esse firewall da rede passa a entender tudo o que trafega, uma vez que está violando o sigilo da conexão. Neste ponto, por exemplo, todas a senhas, incluindo as bancárias, poderão ser vistas pelo administrador de rede. O problema é que os navegadores relatarão que a conexão não parece ser íntegra, uma vez que o certificado do firewall não será reconhecido. Há duas soluções para isso: instalar o certificado do firewall em cada navegador da rede ou instalar um programa “agente” do firewall, que burle as regras. Qualquer uma das duas condições propiciará a violação do sigilo da conexão sem um alerta ao usuário envolvido.
Um indício de uso de SSL inspection é a alteração de certificados digitais. A figura a seguir mostrará o certificado digital obtido via conexão 3G.
É possível observar os campos “Issued To” e “Issued By”. No Issued To há os dados do certificado instalado no servidor de páginas do site GitHub. Já no campo “Issued By”, é possível ver os dados providos pela autoridade certificadora DigiCert[4].
Na próxima figura há o mesmo site, acessado logo em seguida, mas utilizando uma rede que pratica o SSL inspection.
Além do site desfigurado, vários dados do certificado foram removidos ou alterados. O navegador Internet Chromium, que estava sendo utilizado, é um dos programas que mostra claramente esse tipo de ocorrência. Nota-se, inclusive, o protocolo HTTPS riscado, indicando que o mesmo foi violado. Outros navegadores, como o Firefox, permitirão “adicionar uma exceção de segurança”, fazendo com que o site possa ser acessado sem a homologação de certificado, criando a possibilidade de captura de todos os dados que trafegam. É importante relembrar que, caso um agente do firewall estivesse instalado na máquina do usuário, o site apareceria normalmente, sem qualquer anomalia, apesar de haver grande a possibilidade do certificado mostrar dados não originais.
É importante ressaltar que o SSL inspection foi desenvolvido para “vasculhar” conexões de usuários internos e somente em casos especiais. Com outras técnicas mais adequadas, as conexões de usuários externos com os servidores internos poderão ser analisadas de forma mais profissional e menos intrusiva, via proxies reversos.
Conclui-se que é extremamente importante haver um cuidado com excessos no uso do SSL inspection. O simples fato de o recurso existir em um equipamento de firewall adquirido não permite o seu uso indiscriminado. Além disso, em qualquer caso, todos os funcionários e alunos de uma instituição deverão ser alertados, se for o caso, da possibilidade de tal ação na rede interna. Mesmo assim, ordens judiciais ou motivos de força maior não corriqueiros deveriam existir antes do acionamento do recurso contra uma máquina específica, por tempo determinado. Assim sendo, o uso ininterrupto de SSL inspection em toda a rede sempre será considerado como abusivo, podendo constituir crime.
[1] http://www.verisign.com.br
[2] http://www.certisign.com.br
[3] http://www.iti.gov.br/icp-brasil
[4] http://http://www.digicert.com
Tags:abuso, contravenção, crime, dados, firewall, ilegal, ilícito, Internet, invasão, legalidade, legislação, lei, lícito, pessoais, privacidade, proibido, redes, Segurança, senhas, SSL inspection
Posted by Eriberto on jun 4, 2014 in
Debian,
Linux Today I made a little script and I put it in my site... So, you can see the results here:
http://eriberto.pro.br/debian/wheezy-backports_list.txt
More about Debian Backports can be viewed at:
http://backports.debian.org
Enjoy!
Tags:backports, Debian, empacotamento, Wheezy
Posted by Eriberto on fev 2, 2014 in
Linux,
Programas Uma das grandes afirmações da filosofia do Software Livre é que você pode ajudar em um código ou, até mesmo, fazer um trabalho que dele derive.
Como mantenedor Debian, um dos maiores problemas que vejo no mundo livre é o fim de linha ou o abandono de programas úteis para a comunidade mundial. Você que é programador e é apaixonado por SL, já pensou em adotar um código abandonado? Adotar um desses programas lhe traria os seguintes benefícios:
- Você faria algo útil para a humanidade e se sentiria uma pessoa especial.
- Você aprenderia muito com o código abandonado, afinal ele foi criado por um programador que foi reconhecido de alguma forma. Esse programador pode ter abandonado um bom código até mesmo por um motivo grave, como falecimento.
- Você estaria dando atenção a um lado pouco explorado da filosofia do Software Livre.
- Se você precisa fazer um TCC de faculdade, esta é a melhor chance de aprender profundamente sobre um assunto e deixar um trabalho útil como legado.
Uma das formas de encontrar um código abandonado que lhe interesse é pesquisar em grandes repositórios, como o SourceForge ou GitHub, observando as datas das últimas atualizações dos programas. Em seguida, você deve escrever para o autor, perguntando sobre o desenvolvimento do código e especulando se ele pretende dar continuidade. A seguir, em função da resposta, você pode anunciar que quer cuidar do código desde já ou, se achar melhor, você pode fazer um fork com um nome similar. Exemplo: xyzfaztudo vira xyzfaztudo-ng ou xyzfaztudo-up ou faztudo-rob (se seu nome for Roberto, por exemplo). Ou pode usar um nome totalmente diferente. Também é válido.
Uma outra forma de encontrar bons códigos abandonados é olhando a relação de pacotes órfãos no Debian, disponível em https://www.debian.org/devel/wnpp/orphaned_byage. Muitos desses pacotes estão órfãos porque os desenvolvedores dos respectivos programas abandonaram o projeto por algum motivo. Então, em diversos casos, sem o programa atualizado pelo desenvolvedor, torna-se impossível manter o pacote em qualquer distribuição que seja. Dois bons exemplos são:
- html2text: esse utilíssimo programa teve a sua última atualização em 15/01/2004. Uma boa alma o hospeda em http://www.mbayer.de/html2text. Ao conversar com o dono do site, ele me disse que só hospeda o programa para que ele não morra. Mas ele não é programador. Você, leitor que programa em C, poderia adotar esse programa. Há vários patches prontos, feitos no Debian, para corrigir problemas. Você pode ver esses patches em http://sources.debian.net/src/html2text/1.3.2a-16/debian/patches. Há também bugs abertos no Debian, falando sobre problemas do programa, alguns citando a solução. Veja em http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=html2text. Eu gostaria muito de adotar esse pacote no Debian. Mas, para isso, preciso que alguém adote o programa e o seu código fora do Debian. O pacote foi tornado órfão no Debian em 08/09/2009. Detalhes sobre o pacote poderão ser vistos aqui: http://packages.qa.debian.org/h/html2text.html. Outra boa ideia, caso resolva adotar o programa, é buscar por bugs e patches em outras distribuições, como Ubuntu, OpenSUSE, Fedora etc.
- netstat-nat: esse é para quem gosta de programar algo sobre redes. A sua última atualização foi em 2010. Está disponível em http://www.tweegy.nl/projects/netstat-nat. O pacote ficou órfão no Debian e o antigo mantenedor fez a seguinte observação: "estou tornando órfão porque não há mais atividade por parte do desenvolvedor". Detalhes em: http://packages.qa.debian.org/n/netstat-nat.html.
Gostou da ideia? Então, deixe aqui o seu comentário, dizendo qual projeto você adotou ou, até mesmo, passou a integrar.
[]s
Tags:Software Livre
Há algum tempo, neste link, eu falei sobre o fmem, um módulo de kernel que fornece privilégios para que seja possível o dump de memória, muito usado em perícias digitais (forense computacional). Ocorre que o fmem possui algumas limitações, como a aquisição de memória somente até 4 GB. Assim a solução mais moderna e versátil é o LiME.
O objetivo deste post será mostrar, de forma simples e objetiva, como compilar e usar o módulo de kernel LiME, disponível em https://code.google.com/p/lime-forensics. O trabalho se dará no Debian Wheezy (7.0).
Inicialmente, como root, instale os cabeçalhos (headers) do kernel, o gcc e o make. Considerando o uso de um kernel de 64 bits, o comando será:
# apt-get install linux-headers-amd64 gcc make
A seguir, faça download do LiME e, depois, o extraia. A extração se dará com o comando tar:
# tar -xvf lime-forensics-1.1-r17.tar.gz
Como próximo passo, entre no diretório src e compile o código:
# cd src
# make
Observe que será criado um módulo de kernel (extensão .ko). No meu caso, um ls mostra o seguinte:
# ls
disk.c lime-3.2.0-4-amd64.ko lime.h main.c Makefile Makefile.sample tcp.c
Finalmente, carregue o módulo. Será utilizado o comando insmod com algumas opções. Esse carregamento já realizará o dump de memória automaticamente. O comando será o seguinte:
# insmod lime-3.2.0-4-amd64.ko "path=/root/mem.dump format=lime"
Depois do comando anterior, será criado um arquivo em /root, com o nome mem.dump, que conterá o dump da memória. O LiME trabalha com três formatos de dump: raw, padded e lime. O formato raw é o mais puro e fornece uma cópia idêntica do conteúdo da RAM. No entanto, o formato lime, que contém headers extras que controlam endereços de memória por blocos, é entendido pelo analisador Volatility. Assim sendo, este será o método preferencial.
Caso seja necessário realizar um novo dump de memória na máquina, antes de tudo, remova o módulo LiME. Para tanto, utilize o comando:
# rmmod lime
O manual do LiME em PDF, disponível no mesmo site de download, fornece diversas opções, como a aquisição da memória em dispositivos usando Android.
Tags:/dev/mem, computador, dcfldd, dd, dump, fmem, Forense computacional, Linux, memória, perícia digital, Segurança, volatility
Posted by Eriberto on out 7, 2013 in
Debian,
Sistema Operacional Short URL: http://bit.ly/debian_watch
Writing a good watch file for a Debian package is simple. However, several maintainers don't know how to make watches for non trivial sites as Google Pages or Github. Then, my objective is teach a bit about debian/watch.
A conventional debian/watch has two lines: version and site watcher. An example for a simple and trivial site:
version=3
http://f00l.de/pcapfix/pcapfix-(.+)\.tar\.gz
The first line is compulsory and says to Debian watch system (in Debian official project sites) what is the used version and how to behave. Currently, this line is always "version=3". Then, forget this. The last line (site watcher) is responsible by scan the site, searching for versions of the codes (tarballs). This line was made using a simple observation and regular expressions (Perl regular expressions). So, in the upstream site (http://f00l.de/pcapfix), we can point a download shortcut to see the file URL. Please, see the picture below that shows this situation:
PS: to get a summary about Perl regular expressions, go to the site http://www.cs.tut.fi/~jkorpela/perl/regexp.html.
Is possible to see the web link f00l.de/pcapfix/pcapfix-0.7.3.tar.gz and we will try to use it. We should change the version from 0.7.3 to (.+). In Perl regular expressions, .* is treated as anything, except newline, one or more times. Then, we want monitor pcapfix-ANYTHING.tar.gz. The brackets are used to alert the watch system that we are considering as version what can be seen among them. The final situation is http://f00l.de/pcapfix/pcapfix-(.+)\.tar\.gz. Note that the last part (after the last slash) has a regexp and the points was protected by backslashes to avoid an interpretation as any character.
PS: Some people like to use (.*). However, in regular expressions, this is treated as nothing or anything. Then, http://f00l.de/pcapfix/pcapfix-(.*)\.tar\.gz will match with pcapfix-.tar.gz and you should avoid this.
To test a watch file, we need run 'uscan command' from upstream code place (outside of the debian directory, but it must exist; debian/changelog and debian/watch are fundamental to test because uscan will get the local version from the first and compare with results generated by the last).
$ uscan --verbose --report
The result:
eriberto@canopus:/tmp/pcapfix-0.7.3$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
http://f00l.de/pcapfix/pcapfix-(.+)\.tar\.gz
-- Found the following matching hrefs:
pcapfix-0.7.3.tar.gz
pcapfix-0.7.2.tar.gz
pcapfix-0.7.1.tar.gz
pcapfix-0.7.tar.gz
pcapfix-0.6.tar.gz
pcapfix-0.5.tar.gz
pcapfix-0.4.tar.gz
pcapfix-0.3.tar.gz
pcapfix-0.2-real.tar.gz
pcapfix-0.1.tar.gz
Newest version on remote site is 0.7.3, local version is 0.7.3
=> Package is up to date
-- Scan finished
How you can see, all versions were shown and the package is using the lastest release. This was a very easy work. However, we can use another technique, which is more sophisticated. This technique is useful for sites more complex as Google Pages and Github.
The site shown in the last picture has web links. Then, we can collect these web links. To do this, initially, we must use the URL of the site that has the links and (.*). Note that, this time, (.*) will be used to a temporary action only. An example:
version=3
http://f00l.de/pcapfix (.*)
After the uscan command, the output was:
eriberto@canopus:/tmp/pcapfix-0.7.3$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
http://f00l.de/pcapfix (.*)
-- Found the following matching hrefs:
/
/
/blog/
/blog/
/pcapfix/
/pcapfix/
/genmenu
/genmenu
/hacking/
/hacking/
/impressum.html
/impressum.html
/hacking/pcapfix.php
/hacking/pcapfix.php
pcapfix-0.4.png
pcapfix-0.4.png
/hacking/pcapfix.example.txt
/hacking/pcapfix.example.txt
mailto:ruport@f00l.de
mailto:ruport@f00l.de
pcapfix-0.7.3.tar.gz
pcapfix-0.7.3.tar.gz
pcapfix-0.7.3-win32.zip
pcapfix-0.7.3-win32.zip
changelog-0.7.3.txt
changelog-0.7.3.txt
pcapfix-0.7.2.tar.gz
pcapfix-0.7.2.tar.gz
pcapfix-0.7.2-win32.zip
pcapfix-0.7.2-win32.zip
changelog-0.7.2.txt
changelog-0.7.2.txt
pcapfix-0.7.1.tar.gz
pcapfix-0.7.1.tar.gz
pcapfix-0.7.1-win32.zip
pcapfix-0.7.1-win32.zip
changelog-0.7.1.txt
changelog-0.7.1.txt
pcapfix-0.7.tar.gz
pcapfix-0.7.tar.gz
pcapfix-0.7-win32.zip
pcapfix-0.7-win32.zip
changelog-0.7.txt
changelog-0.7.txt
pcapfix-0.6.tar.gz
pcapfix-0.6.tar.gz
pcapfix-0.6-win32.zip
pcapfix-0.6-win32.zip
changelog-0.6.txt
changelog-0.6.txt
pcapfix-0.5.tar.gz
pcapfix-0.5.tar.gz
pcapfix-0.5-win32.zip
pcapfix-0.5-win32.zip
changelog-0.5.txt
changelog-0.5.txt
pcapfix-0.4.tar.gz
pcapfix-0.4.tar.gz
pcapfix-0.4-win32.zip
pcapfix-0.4-win32.zip
changelog-0.4.txt
changelog-0.4.txt
pcapfix-0.3.tar.gz
pcapfix-0.3.tar.gz
changelog-0.3.txt
changelog-0.3.txt
pcapfix-0.2-real.tar.gz
pcapfix-0.2-real.tar.gz
changelog-0.2.txt
changelog-0.2.txt
pcapfix-0.1.tar.gz
pcapfix-0.1.tar.gz
mailto:info@f00l.de
mailto:info@f00l.de
dpkg: error: version 'mailto:ruport@f00l.de' has bad syntax: epoch in version is not number
Newest version on remote site is mailto:ruport@f00l.de, local version is 0.7.3
dpkg: error: version 'mailto:ruport@f00l.de' has bad syntax: epoch in version is not number
=> Newer version available from
http://f00l.de/pcapfix/mailto:ruport@f00l.de
-- Scan finished
Note that all web links in the page are shown. Then, we can use another format in debian/watch to filter the result:
version=3
<URL> <expression to grep>
Yes! You can 'grep' the result (and apply Perl regexp). Then, you may use (observe the space between URL and the regexp):
version=3
http://f00l.de/pcapfix pcapfix-(.+)\.tar\.gz
See the result:
eriberto@canopus:/tmp/pcapfix-0.7.3$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
http://f00l.de/pcapfix pcapfix-(.+)\.tar\.gz
-- Found the following matching hrefs:
pcapfix-0.7.3.tar.gz
pcapfix-0.7.3.tar.gz
pcapfix-0.7.2.tar.gz
pcapfix-0.7.2.tar.gz
pcapfix-0.7.1.tar.gz
pcapfix-0.7.1.tar.gz
pcapfix-0.7.tar.gz
pcapfix-0.7.tar.gz
pcapfix-0.6.tar.gz
pcapfix-0.6.tar.gz
pcapfix-0.5.tar.gz
pcapfix-0.5.tar.gz
pcapfix-0.4.tar.gz
pcapfix-0.4.tar.gz
pcapfix-0.3.tar.gz
pcapfix-0.3.tar.gz
pcapfix-0.2-real.tar.gz
pcapfix-0.2-real.tar.gz
pcapfix-0.1.tar.gz
pcapfix-0.1.tar.gz
Newest version on remote site is 0.7.3, local version is 0.7.3
=> Package is up to date
-- Scan finished
Another example. Please, see the site https://sites.google.com/site/doctormike/pacman.html, that provides the game Pacman for Console (pacman4console in Debian). The picture below shows a link in the site:
The first idea is to use something like this:
version=3
https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz\?attredirects=0
or
version=3
https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz.*
But the results are:
eriberto@canopus:/tmp/pacman4console-1.2$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz\?attredirects=0
uscan warning: In debian/watch,
no matching hrefs for watch line
https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz\?attredirects=0
-- Scan finished
and:
eriberto@canopus:/tmp/pacman4console-1.2$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz.*
uscan warning: In debian/watch,
no matching hrefs for watch line
https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz.*
-- Scan finished
Then, we must use the URL scan method. In a first time use:
version=3
https://sites.google.com/site/doctormike/pacman.html (.*)
The output:
eriberto@canopus:/tmp/pacman4console-1.2$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
https://sites.google.com/site/doctormike/pacman.html (.*)
-- Found the following matching hrefs:
https://sites.google.com/site/doctormike/pacman-1.2.ebuild?attredirects=0
https://sites.google.com/site/doctormike/pacman-1.2.tar.gz?attredirects=0
https://sites.google.com/site/doctormike/pacman-1.1.tar.gz?attredirects=0
https://sites.google.com/site/doctormike/pacman-1.0.tar.gz?attredirects=0
https://sites.google.com/site/doctormike/pacman-1-1.png?attredirects=0
https://www.google.com/a/UniversalLogin?service=jotspot&continue=https://sites.google.com/site/doctormike/pacman.html
/site/doctormike/system/app/pages/reportAbuse
javascript:;
/site/doctormike/system/app/pages/removeAccess
http://sites.google.com
dpkg: error: version 'javascript:;' has bad syntax: epoch in version is not number
Newest version on remote site is javascript:;, local version is 1.2
dpkg: error: version 'javascript:;' has bad syntax: epoch in version is not number
=> Newer version available from
https://sites.google.com/site/doctormike/javascript:;
-- Scan finished
Now, we can make a 'grep' based in https://sites.google.com/site/doctormike/pacman-1.2.tar.gz?attredirects=0 or, simply, .*pacman-1.2.tar.gz.* (it is a grep, man!). Four solutions, among others, are:
version=3
https://sites.google.com/site/doctormike/pacman.html https://sites.google.com/site/doctormike/pacman-(.+)\.tar\.gz\?attredirects=0
version=3
https://sites.google.com/site/doctormike/pacman.html https://sites.google.com/.*/pacman-(.+)\.tar\.gz.*
version=3
https://sites.google.com/site/doctormike/pacman.html .*/pacman-(.+)\.tar\.gz.*
version=3
https://sites.google.com/site/doctormike/pacman.html .*pacman-(.+)\.tar\.gz.*
PS: these examples are available in plain text at http://eriberto.pro.br/files/debian_watch_example.txt.
See the result when using a solution:
eriberto@canopus:/tmp/pacman4console-1.2$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
https://sites.google.com/site/doctormike/pacman.html .*/pacman-(.+)\.tar\.gz.*
-- Found the following matching hrefs:
https://sites.google.com/site/doctormike/pacman-1.2.tar.gz?attredirects=0
https://sites.google.com/site/doctormike/pacman-1.1.tar.gz?attredirects=0
https://sites.google.com/site/doctormike/pacman-1.0.tar.gz?attredirects=0
Newest version on remote site is 1.2, local version is 1.2
=> Package is up to date
-- Scan finished
To Github, I will use as example the project homed at https://github.com/Rup0rt/netmate. In Github, there is a link named release. See the picture below.
If you click over release link, a new page will open and it will show Realeases and Tags links; both have web links that refers to the versions of the releases as, e.g., v0.16. Then, you can use:
version=3
https://github.com/Rup0rt/netmate/releases /Rup0rt/netmate/archive/v(.+)\.tar\.gz
PS: remember that you must use 'https://github.com/Rup0rt/netmate/releases (.*)' for initial scan.
The result:
eriberto@canopus:netmate-0.16$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
https://github.com/Rup0rt/netmate/releases /Rup0rt/netmate/archive/v(.+)\.tar\.gz
-- Found the following matching hrefs:
/Rup0rt/netmate/archive/v0.16.tar.gz
Newest version on remote site is 0.16, local version is 0.16
=> Package is up to date
-- Scan finished
As a new example, go to the site http://eriberto.pro.br/files/myprogram. Consider that you need to check all Linux versions and they are using tar.bz2, tar.gz and tar.xz extensions. Thus, you need to create a rule with a non-capturing group (?:) feature. You can see an example of this below.
version=3
http://eriberto.pro.br/files/myprogram myprogram-(.+)\.tar\.(?:bz2|gz|xz)
Note that (?:bz2|gz|xz) can be used to match lines that have bz2 or gz or xz but it must be ignored in result. Another solution to this case is:
version=3
http://eriberto.pro.br/files/myprogram/myprogram-(.+)\.tar\.(?:bz2|gz|xz)
If needed, you can select between two or more possibilities. Please, see https://github.com/baruch/diskscan/releases. There are two name patterns to the versions. The respective watch is:
version=3
https://github.com/baruch/diskscan/releases .*/(?:diskscan-)?(\d\S+)\.tar\.(?:bz2|gz|xz)
Note that was used (?:diskscan-)? to make diskscan- optional in results. The \d mean 'one digit', as 0-9.
Another resource available is the uversionmangle and dversionmangle. These can be used to modify the vision of the system over the file names. The uversionmangle (u=upstream) is used for upstream site and dversionmangle (d=Debian) is for local file. As an example, consider again the site http://eriberto.pro.br/files/myprogram and local names using '+dfsg-1' suffix, being that '-1' can be another number as '-2.3'. Then, a initial idea of the watch is:
version=3
http://eriberto.pro.br/files/myprogram myprogram-(.+)\.tar\.(?:bz2|gz)
The result:
Newest version on remote site is 2.0, local version is 1.0.2-1+dfsg
=> Newer version available from
http://eriberto.pro.br/files/myprogram/myprogram-2.0.tar.gz
-- Scan finished
As shown, the local version is being composed by upstream version and '-1+dfsg'. We can use dversionmangle to apply a 'sed' command to extract '-1+dfsg'. The final solution is:
version=3
opts=dversionmangle=s/-\d\+dfsg// \
http://eriberto.pro.br/files/myprogram myprogram-(.+)\.tar\.(?:bz2|gz)
See the output:
Newest version on remote site is 2.0, local version is 1.0.2-1+dfsg
(mangled local version number 1.0.2)
=> Newer version available from
http://eriberto.pro.br/files/myprogram/myprogram-2.0.tar.gz
-- Scan finished
Now that you understood how to works debian/watch, is the moment to say that the best combination, in general cases, is (\d\S+), instead of (.+). The \d means a digit (0-9). The \S is any non-whitespace character. Then, using (\d\S+), we will have a digit and, at least, a character as a digit, dot etc. Another best practice is accept a possible change of the file extension by the upstream. Then, is good to use \.tar\.(?:bz2|gz|xz) instead of \.tar\.bz2 or \.tar\.gz or similar. See below some examples:
version=3
http://f00l.de/pcapfix/pcapfix-(\d\S+)\.tar\.(?:bz2|gz|xz)
version=3
https://sites.google.com/site/doctormike/pacman.html .*/pacman-(\d\S+)\.tar\.(?:bz2|gz|xz).*
version=3
http://eriberto.pro.br/files/myprogram myprogram-(\d\S+)\.tar\.(?:bz2|gz|xz)
Finishing, you can see and test several examples of the debian/watch at http://anonscm.debian.org/viewvc/sepwatch/trunk/watchfiles. As said, the site http://www.cs.tut.fi/~jkorpela/perl/regexp.html has an overview about regular expressions. A special attention must be destinated to \d and \S matches because it is very used in watch files. The uscan manpage also has several examples and explanations. There are some important information at https://wiki.debian.org/debian/watch too. The post http://stackoverflow.com/questions/3512471/non-capturing-group explains about non-capturing group feature in Perl regular expressions. Another example of this is at http://deadlytechnology.com/web-development-tips/perl-regex. A good tip is the URL http://www.regexe.com, where you can test the results of the your Perl regular expression. Alternatively, there is http://www.regexplanet.com/advanced/perl/index.html but I prefer the previous link.
I hope this help someone to write his debian/watch files.
-----------------------------------
Update on August 25, 2015:
If needed, you can combine dversionmangle and uversionmangle using a comma as separator. See an example:
opts=uversionmangle=s/-src//,dversionmangle=s/\+dfsg// \
Another possibility is concatenate two actions into uversionmangle or dversionmangle using a semicolon. Look at this example:
opts=uversionmangle=s/-src//;s/-versao/-version/ \
Changing the subject, considering that debian/watch uses Perl regular expressions, you can take advantage of the group capture resource. Please, consider the files at http://eriberto.pro.br/files/myprogram2. There are:
myprogram2-0.1.tar.gz
myprogram2-0.2-beta.tar.gz
myprogram2-0.2.tar.gz
myprogram2-alpha-0.1.tar.gz
myprogram2-beta-0.1.tar.gz
The first problem is that a program version can not start with a alphabetic character. See an example using an initial debian/watch:
version=3
http://eriberto.pro.br/files/myprogram2 myprogram2-(.+)\.tar\.(?:bz2|gz|xz)
see the result:
$ uscan
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
http://eriberto.pro.br/files/myprogram2 myprogram2-(.+)\.tar\.(?:bz2|gz|xz)
-- Found the following matching hrefs:
myprogram2-0.1.tar.gz (0.1)
myprogram2-0.1.tar.gz (0.1)
myprogram2-0.2-beta.tar.gz (0.2-beta)
myprogram2-0.2-beta.tar.gz (0.2-beta)
myprogram2-0.2.tar.gz (0.2)
myprogram2-0.2.tar.gz (0.2)
myprogram2-alpha-0.1.tar.gz (alpha-0.1)
myprogram2-alpha-0.1.tar.gz (alpha-0.1)
myprogram2-beta-0.1.tar.gz (beta-0.1)
myprogram2-beta-0.1.tar.gz (beta-0.1)
dpkg: warning: version '1:beta-0.1-0' has bad syntax: version number does not start with digit
Newest version on remote site is beta-0.1, local version is 0.1
dpkg: warning: version '1:beta-0.1-0' has bad syntax: version number does not start with digit
=> Newer version available from
http://eriberto.pro.br/files/myprogram2/myprogram2-beta-0.1.tar.gz
-- Scan finished
So, the right upstream version must be 0.1-alpha or 0.1-beta, instead of alpha-0.1 or beta-0.1. The second problem is that, for Debian, 0.1 < 0.1-beta. You can analyse this fact using 'dpkg --compare-versions' command. Look at this example (gt = greater than; lt = less than):
$ dpkg --compare-versions 0.1-beta gt 0.1 && echo true
true
In Debian world, the versions can use '~' or '+' to establish a right hierarchy:
0.1~beta < 0.1 < 0.1+beta
So, we need to use 0.1~alpha, 0.1~beta, etc. To change the order of the upstream versions, you can use:
version=3
opts=uversionmangle=s/(alpha|beta)-([\d\.]+)/$2~$1/;s/([\d\.]+)-(alpha|beta)/$1~$2/ \
http://eriberto.pro.br/files/myprogram2 myprogram2-(.+)\.tar\.(?:bz2|gz|xz)
In s/(alpha|beta)-([\d\.]+)/$2~$1/ statement, each group delimited by brackets can be represented by $<number>. So, '(alpha|beta) = $1' and '([\d\.]+) = $2'. Using $1 and $2, we can invert the order, putting a tilde between the groups. Try to understand the second part of the line, that is, s/([\d\.]+)-(alpha|beta)/$1~$2/. This part will act over 0.2-beta. The final result is:
$ uscan
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
opts=uversionmangle=s/(alpha|beta)-([\d\.]+)/$2~$1/;s/([\d\.]+)-(alpha|beta)/$1~$2/ http://eriberto.pro.br/files/myprogram2 myprogram2-(.+)\.tar\.(?:bz2|gz|xz)
-- Found the following matching hrefs:
myprogram2-0.1.tar.gz (0.1)
myprogram2-0.1.tar.gz (0.1)
myprogram2-0.2-beta.tar.gz (0.2~beta)
myprogram2-0.2-beta.tar.gz (0.2~beta)
myprogram2-0.2.tar.gz (0.2)
myprogram2-0.2.tar.gz (0.2)
myprogram2-alpha-0.1.tar.gz (0.1~alpha)
myprogram2-alpha-0.1.tar.gz (0.1~alpha)
myprogram2-beta-0.1.tar.gz (0.1~beta)
myprogram2-beta-0.1.tar.gz (0.1~beta)
Newest version on remote site is 0.2, local version is 0.1
=> Newer version available from
http://eriberto.pro.br/files/myprogram2/myprogram2-0.2.tar.gz
-- Scan finished
That's all. Enjoy!
---
Tags:compose, debhelper, Debian, debian/watch, dversionmangle, empacotamento, Github, Google pages, Jessie, Linux, manual, mentors, newbie, packaging, pacote, Sid, Squeeze, tips, tutorial, uversionmangle, watch, watch.ex, Wheezy
Posted by Eriberto on maio 9, 2013 in
Debian,
Linux,
Sistema Operacional Lintian is a system that checks the Debian Policy when debhelper is building a package in Debian.
Lintian has several verification levels. By default, some are used. However, you can refine it via config file. It's a common error to use the default setting and submit packages with hidden problems to mentors.
To activate all checks in lintian, edit the /etc/lintianrc and enable the following lines:
display-info = yes
pedantic = yes
display-experimental = yes
Be happy with lintian and mentors now!!!
Shortcut to this post: http://bit.ly/lintian
Tags:check, debhelper, Debian, dh_lintian, empacotamento, errors, Jessie, lintian, Linux, mentors, package, packaging, pacote, pedantic, Sid, sponsor, tip, warning, Wheezy