Ir para conteúdo
  • Cadastre-se
Seja bem-vindo
Regras e orientações da nossa comunidade Participe do Discord do ACBr

fba fabio

Membros
 Perfil  Explorar Conteúdo

  • Total de ítens

    16

  • Registro em

  • Última visita

 Tipo de Conteúdo 

Posts postados por fba fabio

    ERRO: "xmlSecNodeSignature" could not be loaded from the dynamic library libxmlsec1

    em ACBrNFe

    Postado

    1 hora atrás, Daniel Simoes disse:

    Por padrão, no Linux, a LibXmlSec é compilada com a MinGW..  e pelo que notamos, o nome padrão dela, quando instalada, é " libxmlsec1.so"

    Isso pode ser uma variação da sua distribuição Linux, a qual você pode facilmente contornar com um Link simbólico..

    Perceba que o {$IFNDEF MSWINDOWS} esta dentro do bloco {$ELSE} do {$IFDEF MSWINDOWS} ou seja, ele nunca irá entrar no {$ELSE} do {$IFNDEF MSWINDOWS} e sempre retornará 'libxmlsec1' sendo que o correto seria retornar 'libxmlsec.so' ou 'libxmlsec1.so', ele não deveria retornar somente o nome da lib sem o '.so' 

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

     

     

    Data de Validade do Certificado já expirou: 30/12/1899

    em ACBrNFe

    Postado

    2 horas atrás, Daniel Simoes disse:

    Parece que mudou a assinatura de alguns métodos que usamos... na versão 1.1

    Teríamos que rever toda a Unit de "Bind"... a gigantesca "OpenSSLExt"  (uma versão estendida da Unit OpenSSL, do FPC)

    Fiz alguns testes (Fedora 28) e as libs estão dispostas da seguinte forma: 

    ls -sal /usr/lib64/libssl*
/usr/lib64/libssl3.so
/usr/lib64/libssl.so -> libssl.so.1.1.0i
/usr/lib64/libssl.so.10 -> libssl.so.1.0.2o
/usr/lib64/libssl.so.1.0.2o
/usr/lib64/libssl.so.1.1 -> libssl.so.1.1.0i
/usr/lib64/libssl.so.1.1.0i

ls -sal /usr/lib64/libcrypto*
/usr/lib64/libcrypto.so -> libcrypto.so.1.1.0i
/usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.2o
/usr/lib64/libcrypto.so.1.0.2o
/usr/lib64/libcrypto.so.1.1 -> libcrypto.so.1.1.0i
/usr/lib64/libcrypto.so.1.1.0i

    A função LoadLibHack que é responsável por encontrar as libs, procura primeiro pela lib sem versão nenhuma, então bastou ajustar para que ele procure primeiro pelo '.10' para que fosse realizado o carregamento da lib correta 

    OpenSSLExt
DE: 
DLLVersions: array[1..16] of string = ('', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3',
                                        '.1.0.2', '.1.0.1','.1.0.0','.0.9.8',
                                        '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4',
                                        '.0.9.3', '.0.9.2', '.0.9.1');           
PARA: 
DLLVersions: array[1..17] of string = ('.10','', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3',
                                        '.1.0.2', '.1.0.1','.1.0.0','.0.9.8',
                                        '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4',
                                        '.0.9.3', '.0.9.2', '.0.9.1');

    Usando a lib da série 1.0 a assinatura ocorreu corretamente tanto usando xsLibXml2 como xsXmlSec e a conexão com o webservice também funcionou normalmente

     

    Fiz alguns testes em C com as duas versões da lib série 1.0.2 e 1.1.0 para o método EVP_DigestInit, que é onde esta ocorrendo o erro usando a versão 1.1 da lib ao tentar assinar usando xsLibXml2. Foi preciso fazer várias pequenas modificações no código em C para funcionar na versão nova.

     

    Atualmente estou usando a versão 1.1 da lib OpenSSL para emissão de NFe e esta rodando corretamente, as exceções ficam por conta da xsLibXml2 que pode ser substituída pela xsXmlSec e o bug do tópico em questão no método GetNotAfter, verificando no site https://www.openssl.org/source/ o suporte a versão da série 1.0.2 (LTS) terminará em 31/12/2019 e eles recomendam que todos migrem para a próxima versão LTS 1.1.1 que tem suporte até setembro de 2023

    • Curtir 2

    Código de barras saindo colorido no Linux

    em Dúvidas Gerais sobre o ACBr

    Postado

    1 hora atrás, fba fabio disse:

    Vou reportar o erro no projeto Fortes Report CE, as vezes algum pequeno ajuste resolva o problema, mas de imediato acredito que incluindo uma diretiva para alterar o tipo de código de barras de bcCode128C para bcEAN128C quando a compilação for realizada no Linux resolva o problema

    Encontrei o problema, esta na propriedade AutoSize ao selecionar bcCode128C e incluir um código de barras com 44 caracteres ele esta definindo o Width para 286 porém desmarcando a opção AutoSize e definindo manualmente o Width para 289 a renderização ocorre corretamente

    bcCode128C.png

    • Curtir 6

    Código de barras saindo colorido no Linux

    em Dúvidas Gerais sobre o ACBr

    Postado

    6 minutos atrás, Daniel Simoes disse:

    Creio que seja algum problema no Fortes Report, na conversão do suporte do Projeto a Linux... 

    Existe uma implementação do DANFE, em LazReport... (mas deve estar um pouco defasada, por falta de uso)

     

    Vou reportar o erro no projeto Fortes Report CE, as vezes algum pequeno ajuste resolva o problema, mas de imediato acredito que incluindo uma diretiva para alterar o tipo de código de barras de bcCode128C para bcEAN128C quando a compilação for realizada no Linux resolva o problema

    • Curtir 1

    Data de Validade do Certificado já expirou: 30/12/1899

    em ACBrNFe

    Postado

    6 horas atrás, Daniel Simoes disse:

    Por isso que você não teve problemas na Assinatura... (o Hash está sendo calculado pela XMLSec)...

    Hoje em dia, o ACBr usa rotinas próprias, para computar a Assinatura digital dos XMLs... isso é bom, pois remove a dependência da XMLSec... Nossas rotinas de calculo de Hash e Sign Digest, estão em: ACBrDFeOpenSSL.pas... e elas são usadas, quando a biblioteca de Assinatura do XML é configurada como xsLibXml2, creio que nesse cenário... você terá novos problemas, com o OpenSSL 1.1

    Ola, você tem razão, ao usar xsLibXml2 quando tenta gerar a NFe ocorre 'ERRO: Access violation', usando a configuração conforme imagem anexa tudo funciona normalmente

    Vou dar uma olhada no código em relação ao uso da xsLibXml2, as vezes com alguns ajustes seja possível rodar no Linux com a Openssl 1.1

    xsXmlSec.jpg

    • Curtir 1

    ERRO: "xmlSecNodeSignature" could not be loaded from the dynamic library libxmlsec1

    em ACBrNFe

    Postado

    A alteração realizada no arquivo Fontes/ACBrOpenSSL/libxmlsec.pas

    Alterada a linha:
    LIBXMLSEC_SO = 'libxmlsec.so';
    para:
    LIBXMLSEC_SO = {$IFNDEF MSWINDOWS}'libxmlsec1'{$ELSE}'libxmlsec.so'{$ENDIF};

    Esta alteração esta gerando o erro abaixo ao tentar gerar/assinar o xml da NFe:
    ERRO: "xmlSecNodeSignature" could not be loaded from the dynamic library libxmlsec1

    Uma solução paliativa para contornar o problema foi criar um link simbólico com o nome libxmlsec1 sem a extensão .so
    ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1

    https://github.com/GabrielF7/ACBrTrunk2/commit/c49df5f71c32474ae5caa9b5b32e4485eca5ba5a#diff-315e5578b57ec7910d57ff00a15b02c2

    libxmlsec.thumb.png.c3f9fe0e26588470e2e4fc7bae3d7649.png

    • Curtir 2

    Data de Validade do Certificado já expirou: 30/12/1899

    em ACBrNFe

    Postado · Editado por fba fabio

    15 horas atrás, Daniel Simoes disse:

    Acho que existe alguma incompatibilidade, também na rotina de Criptografia...

    Você está usando libXMLSec ou LibXML2 para assinar o XML ?

    No Ubuntu após vários testes o que funcionou foi baixar e compilando diretamente do repositório o xmlsec1, no Fedora bastou instalar os pacotes diretamente dos repositórios e criar um link simbólico pois ao realizar o build do Lazarus ele não estava encontrando a lib xmlsec1, abaixo segue o passo a passo que utilizei baseado nas dicas do vídeo https://www.youtube.com/watch?v=wU8KRNMwUaw 

    #UBUNTU 18.04
apt install libxml2-dev
apt install libltdl-dev
apt install libssl-dev
wget http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.27.tar.gz
tar -zxvf xmlsec1-1.2.27.tar.gz
cd xmlsec1-1.2.27
./configure
make
make install
    #FEDORA 27/28
yum install libxml2-devel
yum install libxslt-devel
yum install libtool-ltdl-devel
yum install openssl-devel
yum install xmlsec1
ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1.so

     

    • Curtir 3

    Código de barras saindo colorido no Linux

    em Dúvidas Gerais sobre o ACBr

    Postado

    14 horas atrás, Daniel Simoes disse:

    O mais estranho é que o problema não ocorre no Windows..

    O problema ocorre no Linux, usando o Filtro para PDF ?

    Acredito que não tenha relação com o Filtro para PDF, pois olhando o código fonte do fortes é possível verificar que é feita a instanciação de um objeto canvas que gera um bitmap como saída, e o erro ocorre durante a manipulação do componente ao ser inserido diretamente em um form como pode ser visto na imagem que postei

    • Curtir 2

    Data de Validade do Certificado já expirou: 30/12/1899

    em ACBrNFe

    Postado

    12 horas atrás, Daniel Simoes disse:

    Realmente o ACBrOpenSSL (ainda) não é compatível com a séria 1.1 do OpenSSL...

    Não é possível usar/instalar uma versão da Série 1.0, do OpenSSL ?

    O único problema relacionado ao OpenSSL até o momento foi no método GetNotAfter

    Estou usando o ACBrMonitor PLUS para emissão de NFE rodando no Ubuntu 18.04

    Compilado com Lazarus 1.8.0 2018-03-17 FPC 3.0.2 no Fedora

    Código de barras saindo colorido no Linux

    em Dúvidas Gerais sobre o ACBr

    Postado

    10 horas atrás, Juliana Tamizou disse:

    Boa tarde.

    Após realizar diversos testes, notamos que a única diferença entre o tipo EAN128C e Code128C é a inclusão do digito verificador...infelizmente a alteração proposta não poderá ser aplicada pois poderia causar a quebra as aplicações que utilizam a implementação atual. 

    Tente verificar se não trata-se de algum problema relacionado a drivers.

    Att.

     

    Realizei novos testes e verifiquei que o problema ocorre devido a variação na quantidade de caracteres conforme pode ser visto na imagem em anexo. O fato de funcionar usando o bcEAN128C com Ratio 2 se deve realmente ao fato da inclusão do dígito verificador fazendo com que o código resultante fique em 46 caracteres, aparentemente o problema esta no fortesreport-ce

    128c.png

    • Curtir 2

    Data de Validade do Certificado já expirou: 30/12/1899

    em ACBrNFe

    Postado

    Este problema aparentemente tem relação com a versão do OpenSSL (estou usando OpenSSL 1.1.0i-fips 14 Aug 2018), acredito que o método da lib openssl que retorna a data de validade do certificado foi modificado e esta retornando nil, uma solução temporária que encontrei para bypass o problema foi o seguinte:

    Alterar o método ./Fontes/ACBrDFe/ACBrDFeOpenSSL.pas linha 136
      

    function GetNotAfter( cert: pX509 ): TDateTime;
var
  Validade: String;
  notAfter: PASN1_TIME;
begin

//  *** remover as linhas comentadas abaixo: ***
//  notAfter := cert^.cert_info^.validity^.notAfter;
//  Validade := {$IFDEF DELPHIXE4_UP}AnsiStrings.{$ENDIF}StrPas( PAnsiChar(notAfter^.data) );
//  SetLength(Validade, notAfter^.length);
//  Validade := OnlyNumber(Validade);
//  if notAfter^.asn1_type = V_ASN1_UTCTIME then  // anos com 2 dígitos
//  Validade :=  LeftStr(IntToStrZero(YearOf(Now),4),2) + Validade;
//  Result := StoD(Validade);}
//  *** adicionar apenas o Result abaixo que equivale retornar como data de validade a data 22/02/2022 ***
      Result := StoD('20220222000000');
end;

    Após a alteração abrir ./Pacotes/Lazarus/ACBrDFe/ACBrDFeComum.lpk e compilar novamente

    • Curtir 1
×
×
  • 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.