Ir para conteúdo
  • Cadastre-se

dev botao

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


  • Este tópico foi criado há 2793 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

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 '

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

  • Fundadores

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

  • Curtir 2
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

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

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

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.

  • Curtir 2
Link para o comentário
Compartilhar em outros sites

  • Fundadores

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"

  • Curtir 1
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • 2 semanas depois ...

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 por Allan Wolski
Link para o comentário
Compartilhar em outros sites

  • Fundadores

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

  • Curtir 5
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

Ó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.

  • Curtir 1

Marcos Douglas B. Santos
www.ObjectPascalProgramming.com

Link para o comentário
Compartilhar em outros sites

  • Fundadores

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 

  • Curtir 2
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

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?

  • Curtir 1

Marcos Douglas B. Santos
www.ObjectPascalProgramming.com

Link para o comentário
Compartilhar em outros sites

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,

  • Curtir 2

André Medeiros

Link para o comentário
Compartilhar em outros sites

  • Fundadores
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}
            

 

  • Curtir 2
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

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 por Allan Wolski
Respondi ao mesmo tempo que o Daniel. XD
  • Curtir 1
Link para o comentário
Compartilhar em outros sites

  • Fundadores

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

  • Curtir 2
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

 

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 por mdbs99
  • Curtir 2

Marcos Douglas B. Santos
www.ObjectPascalProgramming.com

Link para o comentário
Compartilhar em outros sites

  • 4 meses depois ...

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

logo-keruak.png

 André Medeiros

 Estratégia & Negócios
 +55 11 3010 0000

url-keruak.pngfacebook-keruak.pngespaco.pnglinkedin-keruak.png

Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 2793 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...
The popup will be closed in 10 segundos...