Olá Fernando,
> Bom dia, Herbert.
>
> Desculpe pela intromissão, mas dei uma pesquisada na sua dúvida.
Obrigado pela ajuda.
>
>
> On 06/07/2016 05:11 PM, Herbert Fortes (hpfn) wrote:
> > Olá,
> >
> > Estou preparando um NMU para o pacote tzc. Último
> > upload do mantenedor em 2005. Este é o quarto.
> >
> > Tem dois lintian sobre hardening. Se colocar
> > hardening=+all no debian/rules o pacote não
> > constrói. Então fiz:
> >
> > - bindnow. Tirei colocando no debian/rules:
> > export DEB_BUILD_MAINT_OPTIONS := hardening=+bindnow
> > - pie: Alterei o Makefile adicionando as opções:
> > -fPIE -pie -O2 -fstack-protector-strong -Wformat
> >
> > Assim o pacote constrói sem os dois lintians. O complemento
> > '-O2 -fstack-protector-strong -Wformat' é porque o 'blhc' reclama.
> > Ele ainda reclama de '-Werror=format-security', mas se isso
> > for adicionado o pacote não constroi:
> >
> > gcc -g -O -Wall -DINTERREALM -fPIE -pie -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c -o tzc.o tzc.c
> > tzc.c: In function ‘check’:
> > tzc.c:390:7: error: format not a string literal and no format arguments [-Werror=format-security]
> > com_err(__FILE__, e, s);
> > ^
> > tzc.c: In function ‘warn’:
> > tzc.c:398:7: error: format not a string literal and no format arguments [-Werror=format-security]
> > com_err(__FILE__, e, s);
> > ^
> > tzc.c: In function ‘send_zgram_to_one’:
> > tzc.c:713:33: error: format not a string literal and no format arguments [-Werror=format-security]
> > com_err(__FILE__, retval, bfr);
> > ^
> > cc1: some warnings being treated as errors
> > <builtin>: recipe for target 'tzc.o' failed
> >
> > Acho que 'com_err' é do pacote comerr-dev.
> >
> > Tem solução ? Li isso[0], mas o arquivo é de outro
> > pacote.
> >
> > [0] -https://fedoraproject.org/wiki/Format-Security-FAQ
> Aparentemente é mesmo o que está descrito nesse FAQ. A segunda resposta
> para esta pergunta do stackoverflow [1] dá um bom exemplo dessa prática.
>
> [1]
> http://stackoverflow.com/questions/9707569/c-array-warning-format-not-a-string-literal
>
> Nesse caso específico, em `man com_err`:
> void com_err (const char *whoami, long code, const char *format, ...);
>
> Baseado na descrição:
> "(...) and a string produced using the format string and any following
> arguments, in the same style as fprintf(3)."
>
> Eu fiz alguns testes colocando o terceiro argumento de com_err das
> seguintes formas:
> - string literal:
> com_err(__FILE__, e, "This is an error with string literal");
>
> - string de formatação
> com_err(__FILE__, e, "%s", s);
>
> Código do teste:
>
> //test_file.c
> #include <stdio.h>
> #include <string.h>
> #include <et/com_err.h>
>
> int main (){
> char s[20];
> int e = 0;
>
> strcpy( s, "This is an error");
>
> com_err(__FILE__, e, "%s", s);
> com_err(__FILE__, e, "This is an error with string literal");
> }
>
> Compilação e execução (não houve erros ou warnings):
>
> $ gcc -g -O2 -Wall -fPIE -pie -fstack-protector-strong -Wformat
> -Werror=format-security -lcom_err test_file.c -o test_file
> $ ./test_file
> test_file.c: This is an error
> test_file.c: This is an error with string literal
>
> Concluindo, creio que no caso do tzc, uma saída viável seria implementar
> a utilização do com_err com a formatação.
Vou ver aqui agora. Mas estou meio em dúvida. Tive uma
situação semelhante, com o libgphoto2, tempos atrás. E
o upstream contornou de forma diferente. Fez dois patches[0]
de tamanhos considerável. (caso tenha interesse - no_sprintf_chdk*)
[0] - https://anonscm.debian.org/cgit/pkg-phototools/libgphoto2.git/commit/?id=14e8b99a0872a2e4d89ca278a4ab6778f790b80f
>
> > O debian/rules:
> > #!/usr/bin/make -f
> >
> > #export DH_VERBOSE=1
> >
> > export DEB_BUILD_MAINT_OPTIONS := hardening=+bindnow #,+pie
> >
> > ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
> > CFLAGS += -g
> > endif
> > ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
> > INSTALL_PROGRAM += -s
> > endif
> >
> > %:
> > dh $@
> >
> > Para onde vai a 'INSTALL_PROGRAM' ? O pacote não
> > tem repositório, mas ela não aparece em nenhum outro
> > lugar.
> Eu não encontrei nada muito relevante com relação a isso :(
Obrigado mesmo assim.
abraço,
--
Herbert Parentes Fortes Neto (hpfn)