[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority



Let me add here some of the history about rnetclient and IRPF Livre,
concerning legal and government matters.

As already said, Oliva has been publishing IRPF Livre for a while. He
decompiled that software when it was using GPL libraries, which would
make it GPL software, even though SERPRO or Receita didn't distribute it
on the same terms. That could be interpreted as a legal liability, but
he has not found any problems since then. Here is what has happened
instead.

As Sergio also pointed out, Oliva has gone through the process of trying
to get the software released, claiming that recent law for transparency
meant the government needed to publish it. SERPRO, who is the developer
of the software, claimed there was secrets in the software that would
allow people's income to be leaked. That is a lie! As Oliva pointed out
in his counter-claim, his own IRPF Livre would allow such a leak if that
was true. And that would be a huge security breach in the whole
process of tax paying/refund. Unfortunately, the judge decided against
the publishing of the software. But Oliva stated that he has done the
reverse engineering, publishes the software, and no action against him
has been taken.

When I was developing rnetclient, I found some concerning problems in
its trust model (software trusts certificate that is shipped with
itself, certificate has a weak password, easily found on the software,
even software hashing checking can be easily circumvented, software is
not distributed with any signature - not even over https). I thought
that publishing that would put me into trouble. I gave a talk on a big
event in Brasil (FISL, >5k people, 300 watched the talk live, video was
published, SERPRO president was at FISL), and no action has been taken
against me. Oliva and I even talked to SERPRO president at the time, he
couldn't care less, or even seemed favorable to what we were doing.

I have been shipping rnetclient since then, 2013. This year I even
managed to have it updated at the same day that Receita has published
its own software (they didn't do Betas this year). The fix came the next
day. I have an intention to publish a version that should work for years
to come, until the protocol breaks from what it has been for the last 5
years. And, in fact, it's still useful to submit corrections to previous
years files. So, if you have to publish 2013 and 2014 again for any
reason, 2015.1 can be used. And the software will still be useful for at
least the next 5 years, when people might still want to resubmit their
2015 files. Unless Receita breaks the whole thing, as I mentioned, but
hasn't done for at least the last 5 years.

About my own process of reverse engineering: I did some decompiling and
read some of the code. I wrote a very small Java class to override the
certificate verification, allowing me to do some MITM. Most of the
process after that involved me writing tests to simulate a server and a
client, and see how the client and server responded. Reading the code
just helped me get the basics on the encoding so I could write the
tests. After that, I wrote the program from scratch. Even though it was
not completely clean room, it's hard to conceive there was any copy of
SERPRO's code. Their code is in Java, with its own APIs, I used C, with
GNUTLS, BSD sockets, zlib, my own decoding of the file that came after I
started writing the tests (so I didn't read any code related to that).

Also, Brazilian law says:

" Art. 6º Não constituem ofensa aos direitos do titular de programa de
computador:

[...]

III - a ocorrência de semelhança de programa a outro, preexistente,
quando se der por força das características funcionais de sua aplicação,
da observância de preceitos normativos e técnicos, ou de limitação de
forma alternativa para a sua expressão; "

Which means that it's not a copyright infringement when a program is
similar to a preexisting one because of its functional
characteristics, or because it follows technical or normative
references, or there is a limitation for other forms of expression.

Hope that helps moving the discussion forward. I, at least, found it
delightful to write this for posterity.

Cascardo.

Attachment: signature.asc
Description: Digital signature


Reply to: