ACBrNFe, ACBrNFSe, ACBrCTe e etc... Funcionando no Linux 64 bits

[Jadiel Sousa]

Olá, pessoal.

Eu gostaria de poder ao menos o evento AntesdeAssinar do componente, mas não sei como fazer.

Eu usei o TProcess pra tentar fazer a assinatura chamando o xmlsec1, porém o nó da assinatura não está no XML e por isso o arquivo não é assinado.

Se alguém poder dar uma luz eu agradeço

Linha de comando do TProcess:

'xmlsec1 --sign --output assinado.xml --pksc12 certificado.pfx --pwd 123 nota.xml '

[Daniel Simoes]

Importante descoberta... obrigado...

Vou fazer alguns testes...

No FPC, um Unsigned Int de 4 bits seria o Cardinal, "longword"

http://www.freepascal.org/docs-html/ref/refsu5.html

[Allan Wolski]

Outro detalhe importante, pelo menos em Delphi, seriam os Pointer operations:

Citar

The size of all pointers has changed, as follows:

• On the 32-bit Windows platform, a pointer is 4 bytes.
• On the 64-bit Windows platform, a pointer is 8 bytes.

http://docwiki.embarcadero.com/RADStudio/Berlin/en/Converting_32-bit_Delphi_Applications_to_64-bit_Windows
http://docwiki.embarcadero.com/RADStudio/Berlin/en/64-bit_Windows_Data_Types_Compared_to_32-bit_Windows_Data_Types

Segue cópia dos meus fontes modificados com base nas alterações propostas pelo André.

ACBr x64.zip

[Allan Wolski]

Pesquisando mais um pouco encontrei no stackoverflow um relato do mesmo problema com Python.
Mais uma vez a solução está relacionada ao flag XMLSEC_NO_SIZE_T, porém não faço ideia se isso pode ser passado através de alguma função para a DLL ou se seria apenas uma diretiva de compilação.

http://stackoverflow.com/questions/13071246/xmlsec1-sign-works-on-command-line-but-fails-on-python-code
https://github.com/aricaldeira/pyxmlsec

Acredito que esta bandeira precisa ser desativada pra compilação das DLL.

Avancei um pouco nos meus testes, conseguindo preencher a tag <DigestValue>, porém o <SignatureValue> e <X509Certificate> ainda ficam em branco.

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <Reference URI="#ID2102104116071066568600019355000000000530100015312701">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue>yvhVfl3NaLjH6hKThpde0bTN3nw=</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue/>
    <KeyInfo>
      <X509Data>
        <X509Certificate/>
      </X509Data>
  </KeyInfo>
</Signature>

Pra este teste eu criei um projeto novo e chamei os métodos do XMLSec diretamente, sem passar pelo ACBr.
Além disso carreguei o certificado com xmlSecCryptoAppKeyLoad ao invés de xmlSecCryptoAppKeyLoadMemory.

Aguardo resultado dos seus testes Daniel e demais colegas.
Att.

[Daniel Simoes]

Testei as modificações..mas sem sucesso, no Lazarus 64 FPC 3.0... Os tópicos encontrados parecem relatar exatamente o problema que estamos enfrentando...

Ele sempre falha ao chamar o método:

    { sign the template }
    SignResult := xmlSecDSigCtxSign(FdsigCtx, SignNode);    

Talvez a solução seja recompilar a XMLSec no Windows sem o flag " XMLSEC_NO_SIZE_T"

[Allan Wolski]

Instalei o Microsoft Build Tools 2015 e recompilei a DLL, porém mesmo depois de muitas tentativas ainda não tenho uma versão funcional da XMLSec em 64 bits.
O maior problema são os erros de compilação e as várias dependências que a DLL possui.

Enviei um e-mail ao responsável pelos binários do Libxml e a resposta foi curta e direta.

Citar

Hi,

 

I built the binaries without local modifications. Just got the sources and built it. I shall keep it that way for the time being. With the rise of MSYS2 these binaries will become obsolete anyway.

 

Ciao,

Igor 

 

Editado 18 Outubro, 2016 por Allan Wolski

[Daniel Simoes]

Acredito  ter conseguido resolver o problema... Commit [r12508]

Citar

24/10/2016
-- libxml2, libxmlsec, libxslt --
[-] Correção para suporte de libxmlsec em 64 bits. Corrigindo falha ao Assinar XML
    http://www.projetoacbr.com.br/forum/index.php?showtopic=25670
[*] Ajuste para permitir o uso de Libxml2, libxslt, libxmlsec compiladas por
    MinGw (default em Win64)
    ftp://ftp.zlatkovic.com/libxml/64bit/ (por: DSA)

Após comparar detalhadamente a declaração de várias estruturas e tipos, de libxmlsec.pas com as declarações em C... Notei que a seguinte declaração poderia ter variação em 32/64 bits

-      time_t = LongInt;
+      time_t = SizeInt;

No código original estava como "LongInt", mas time_t deve ser definido como Int64 (quando compilado em 64 bits)

Por favor atualizem e testem... As DLLs de 64  bits podem ser baixadas em:  ftp://ftp.zlatkovic.com/libxml/64bit/

No mesmo endereço, temos as DLLs de 32bits, porém compiladas com o MinGW... (usam a mesma nomenclatura das DLLs de 64 bits)... Vou subir essas DLLs para o nosso SVN

[mdbs99]

Ótima notícia!

5 horas atrás, Daniel Simoes disse:

...porém compiladas com o MinGW... (usam a mesma nomenclatura das DLLs de 64 bits)... Vou subir essas DLLs para o nosso SVN

Quando você diz compiladas com MinGW, muda alguma coisa?
Após atualizar o fontes, obrigatoriamente tenho que atualizar as DLL de 32 bits?

Obrigado.

[Daniel Simoes]

Não precisa atualizar as DLLs 32 bits... Voce deve "ligar" a diretiva de compilação em ACBr.inc, apenas se você decidir usar a versão 32 que está disponível no link indicado no change-log 

[mdbs99]

Agora fiquei confuso.

Pensando apenas em 32 bits, tem vantagem ou desvantagem usar uma ou outra versão?

E quando eu for migrar para 64 bits, o ACBr irá "ligar" a diretiva automaticamente quando for 64 ou preciso fazer isso manualmente caso opte por usar essa versão?

[almp1]

Olá Daniel obrigado pela ajuda !

Fiz teste no seguinte ambiente

Linux CentOS 7 64 bits
FPC 3.0
Lazarus 1.6

Consegui assinar e transmitir a NFe normalmente

No ambiente 32 bits tudo continua funcionando normalmente também

Abraços,

[Allan Wolski]

Que ótima notícia, Daniel.

Testei no Windows com Delphi 10.1 Berlin e consegui assinar o XML com sucesso.
Compilando em 32 bits tudo continua funcionando normalmente também.

Muito obrigado Daniel e os demais colegas que contribuíram para este resultado.
Att. 

[Daniel Simoes]

49 minutos atrás, mdbs99 disse:

Agora fiquei confuso.

Pensando apenas em 32 bits, tem vantagem ou desvantagem usar uma ou outra versão?

E quando eu for migrar para 64 bits, o ACBr irá "ligar" a diretiva automaticamente quando for 64 ou preciso fazer isso manualmente caso opte por usar essa versão?

Acredito que não exista vantagem de desempenho usar a versão 32 bits, compilada com MinGW... A não ser que você queira manter uma padronização dos nomes das DLLs que o seu sistema deve distribuir, seja em 32 ou 64

Sim, o ACBr ligará a diretiva USE_MINGW, quando a CPU é 64 bits... veja no final de ACBr.inc

// Ative a diretiva abaixo, para usar a Libxml2, libxslt, libxmlsec compilada
// com MinGw ftp://ftp.zlatkovic.com/libxml/64bit/
{.$DEFINE USE_MINGW}
{$IfDef CPU64}
 {$DEFINE USE_MINGW}
{$EndIf}  

 

 

Na prática,isso apenas afetará a maneira que a libxmlsec.pas (e demais), procuram pelas DLLs (o nome da DLL)

{$IFDEF MSWINDOWS}
  {$IFDEF USE_MINGW}
    LIBXMLSEC_SO = 'libxmlsec1.dll';
  {$ELSE}
    LIBXMLSEC_SO = 'libxmlsec.dll';
  {$ENDIF}
{$ELSE}
  LIBXMLSEC_SO = 'libxmlsec.so';
{$ENDIF}
            

 

[Allan Wolski]

48 minutos atrás, mdbs99 disse:

Agora fiquei confuso.

Pensando apenas em 32 bits, tem vantagem ou desvantagem usar uma ou outra versão?

E quando eu for migrar para 64 bits, o ACBr irá "ligar" a diretiva automaticamente quando for 64 ou preciso fazer isso manualmente caso opte por usar essa versão?

Marcos, para compilação em 32 bits não há necessidade de alteração alguma. Pode continuar utilizando da forma como vinha fazendo.
Para compilação em 64 bits o ACBr irá definir a diretiva USE_MINGW automaticamente.

Editado 24 Outubro, 2016 por Allan Wolski
Respondi ao mesmo tempo que o Daniel. XD

[Daniel Simoes]

Apenas para informar... As DLLs de 64 Bits já estão no SVN, em:

\ACBr\DLLs\XMLSec\MinGW\64

Elas devem ser copiadas para: A mesma pasta da sua aplicação (.EXE) ou C:\Windows\System32

[mdbs99]

 

35 minutos atrás, Daniel Simoes disse:

Acredito que não exista vantagem de desempenho usar a versão 32 bits, compilada com MinGW.

Ok!

35 minutos atrás, Allan Wolski disse:

Marcos, para compilação em 32 bits não há necessidade de alteração alguma. Pode continuar utilizando da forma como vinha fazendo.
Para compilação em 64 bits o ACBr irá definir a diretiva USE_MINGW automaticamente.

Ok, obrigado!

Editado 24 Outubro, 2016 por mdbs99

[André Medeiros - KRK]

Olá Amigos

Estou usando o ambiente Linux de 64bits par enviar NFSe para SP. Os XMLS são construídos de forma correta, ou seja, estamos ok em relação a assinatura. Porém no momento do envio recebo a mensagem Erro interno: 0 Erro HTTP: 400. 

Poderiam me dar uma ajuda de como solucionar este problema !

Grato

[Daniel Simoes]

Por favor não crie vários tópicos repetidos... isso é contra as regras do fórum... continue em: