 Olá, a gente já pode começar, oi todo mundo, meu nome é Ellen, eu trabalho na colabora, sou programadora e aqui hoje a gente vai falar sobre bootseguro no Debian, quando e como, certo? Vamos começar. Então, o que a gente vai falar aqui? Vamos começar com o contexto, explicar um pouco para vocês o que é o bootseguro, o objetivo no Debian com isso e algumas inconveniencias que a gente vai tratar. O que é o Shin? Vamos fazer um overview dos pacotes a mais que vamos ter, que são os pacotes sign-in. Vamos ver como o serviço de assinatura, que é o sign-in service, vai funcionar. Vamos ter um pacote template também, vamos ver o que ele é e o estado atual. Essa apresentação aqui, eu estou trazendo aqui fresh news, notícias bem recentes, porque é o resultado de um sprint que a gente teve de Secure Boot, que foi semana passada, acabou domingo, na verdade, domingo passado e eu fiz esses slides essa semana, então, perdão, se faltou alguns diagramas para ficar um pouco mais didático, eu tentei fazer o mais didático que eu podia e esse sprint foi super produtivo, a gente resolveu em um dia, o que a gente não resolveu em dois anos discutindo o problema online, por e-mail e depois esse um dia foi só a implementação, então conseguimos avançar bastante nesse quesito. Essa apresentação eu vou mostrar para vocês qual é a infraestrutura e como decidimos implementar o boot-seguro no Debian, certo? Tão contexto, o que é o boot-seguro? Você tem na sua máquina o firmer, o firmer carrega o bootloader do disco, o bootloader então carrega o sistema, certo? Então, no nosso caso, na verdade, a gente tem o FE, que também é chamada de Bills, não é muito certo esse termo, mas vamos chamar de Bills, que carrega o groovy e que carrega o linuxcare. O boot-seguro, ele vai proteger aqui contra algum atacante remoto que tenta comprometer o seu sistema. É importante ter em mente que é apenas uma proteção, um ataque remoto e não uma pessoa que tenha acesso físico à sua máquina, ao seu equipamento e aí a gente vai entender um pouco por que. Então, como funciona esse negócio de boot-seguro? Então, o seu firmer, no caso o FE, a sua Bills, ele vai possuir um conjunto de certificados embutidos que você não consegue modificar se você não tem acesso físico na máquina e, enfim, é isso e esse certificado, esse firmer vai carregar então o bootloader, que é o groovy, vai verificar antes de executar o groovy se essa imagem foi assinada por alguma autoridade correspondente aos certificados que o firmer tem, no nosso caso o que a gente quer é que esse groovy seja assinado pelo Debian, então o nosso firmer só vai carregar códigos assinados pelo Debian, vai verificar essa assinatura e se a assinatura for OK, o firmer executa o groovy e dentro do groovy a gente tem a mesma lógica para carregar o próximo etapa, que é o kernel. Então, o groovy vai possuir um certificado embutido e ele só vai executar os linos externos se ele tiver, se a assinatura corresponder à imagem carregada, certo? Então, isso que eu quero deixar claro, está funcionando? Isso que eu quero deixar claro é que é só contra ataques remotos mesmo, pois a especificação da UEFI permite alteração desses certificados apenas com um acesso físico à máquina e isso é feito e garantido através do negócio que a gente chama de serviços de boot, que só funcionam realmente se você tiver acesso físico à máquina e não confundam o Secure Boot com o Trusted Boot ou o Measure Boot, que esses sim vão proteger a sua máquina contra ataques se a pessoa tiver acesso físico à sua máquina, tá? Então, resumo, vou chegar lá, certo? Então, em resumo, a gente tem o nosso firmware, o UEFI, que vai carregar o groovy assinado, que vai carregar a imagem do Linux kernel assinada, certo? Então, se o bootloader ou a imagem do kernel foi comprometida, o sistema ele não vai botar. Ele vai decidir que essas imagens estão comprometidas e vai te dar uma mensagem de erro e não vai botar. Por exemplo, só ataques remotos. Vamos supor que você tenha um servidor na cloud e tem gente que conseguiu tomar controle da sua máquina, conseguiu o acesso de root, fez o ssh e quer corromper a sua imagem do Linux, quer trocar o seu Linux por outro, um outro para, sei lá, te grampiar, por exemplo. Então, essa pessoa não vai conseguir fazer isso. Pra ela conseguir fazer isso, ela vai ter que ir lá na sua máquina e fazer. Então, é pra esse tipo de ataque. Alguma dúvida em relação ao bootseguro? De forma geral, até agora? Não, beleza. Então, vamos continuar. Então, os objetivos do Debian. A gente quer botar apenas o group e o Linux kernel que foram assinados pelo Debian quando essa funcionalidade do Secure Boot estiver habilitada, certo? E queremos também fazer uma infraestrutura em que esse esquema de assinatura seja disponível, assim, seja fácil, extensível para dar mais pacotes. Essas imagens vão ser assinadas por uma chave privada do Debian. Por segurança, essa chave privada do Debian está guardada dentro de um hardware, de um token, que na verdade é um Ubiquinano, certo? Por segurança, não é para sair desse hardware. E você não pode dar acesso a qualquer desenvolvedor, a qualquer empacotador a usar. Então, você não pode dar uma cópia da chave privada para todo mundo. Então, a gente tem que ter uma estrutura para só permitir as pessoas autorizadas a terem as suas imagens assinadas. Então, onde isso seria aplicável? Tem o domínio de embarcado. Eu assisti uma palestra da Free Electrons há pouco tempo, que agora se chama bootlin. Eles estavam explicando como eles implementaram todo o esquema de boot seguro numa máquina ARM que eles fizeram para um cliente e eles usavam o que o cliente não queria de forma nenhuma que alguém pudesse mudar todo o esquema de boot. E aí, inclusive, eles fizeram colocar certificados em uma memória read-only mesmo, em Fuse, para não realmente nem certificado por esse modificado. E uma coisa interessante é que eles tenderam, não só até o Linux kernel, mas também verificavam toda a parte do userland, que eles faziam verificação de assinatura. E em servidores de Clownd, é muito usado, então você tem uma máquina remota, você não tem acesso a ela, as pessoas geralmente não têm acesso a ela, você quer assegurar dentro da máquina remota que ninguém invadiu o seu sistema e corrompeu ele. E é lógico que aí você depende da integridade do hypervisor, mas aí não é tanto a sua jurisdição, é o provedor de Clownd que vai tomar conta, certo? E também temos notebooks pessoais, que é uma discussão mais, infelizmente, ou felizmente, não sei, aí depende da posdivissa, vem com a sabilidade Secure Boot ativado e atualmente vocês não conseguem instalar Debian se o Secure Boot estiver ativo. Certo? Então o inconveniente aqui é o que o certificado da Debian não vem de fábrica nas máquinas que a gente compra, não veio de fábrica nessa máquina e eu duvido muito que veio de fábrica nas máquinas que vocês compraram, certo? Para o usuário final, né? E então, para você, se você quiser instalar Debian na sua máquina, ou você desabilita o Secure Boot na BIOS, que é o que a gente faz atualmente, ou a gente assina tudo e faz com que os nossos usuários instalem o certificado do Debian na mão, na BIOS, mas isso é muito inconveniente para novato, isso é meio avançado já, você não vai querer que toda pessoa que instala Debian faça essas coisas e desabilitar o boot seguro para uma pessoa que não conhece é uma coisa muito assustadora, assim. Você vai entrar, você é uma pessoa que não conhece, você obriga ela, ah, desabilita, eu assuto de segurança aí, é a mesma coisa que falar, sei lá, para os meus pais desabilitarem o antivírus para entrar no acesso ao banco, eu acho. É meio assustador. É meio assutador para quem está começando. E também é inconveniente para a cloud, porque as pessoas não têm acesso físico à máquina para ir lá instalar o certificado a eles mesmo. Então, o que vem nas máquinas que a gente compra? Então, a maioria das máquinas que vem com o selo, que vem certificado pela Microsoft, que é a maioria das máquinas, vem com o certificado da Windows, embutido para boot, certo? Para fazer a cadeia de secure boot. Uma coisa que a Microsoft foi legal, foi que no certificado é obrigatório para os fabricantes de mac, de máquina, por exemplo, a Dell, a ASUS, colocarem na BIOS dela uma opção para que a pessoa ou consiga desativar o boot seguro ou consiga colocar seus próprios certificados. Então, todas as máquinas que vocês têm aí, vocês podem colocar o instalar, o próprio certificado de vocês. Se vocês quiserem assinar o próprio group de vocês, o próprio lino esquerdo, vocês podem colocar o próprio certificado dentro da BIOS, do firmware, certo? E uma coisa também que a Microsoft foi legal, nessa história toda, é que eles disponibilizam um serviço de assinatura, caso você queira distribuir o seu software por aí, queira que ele seja butável, e não queira obrigar a pessoa a desabilitar o boot seguro ou instalar o próprio certificado. Então, se qualquer um pode fazer, claro que tem um processo de revisão, vocês podem pegar e... Testando um, dois, três. Melhorou? Vocês podem assinar o próprio group de vocês e pedir para a Microsoft assinar para vocês, certo? Então, poderia falar, vamos fazer isso para facilitar os usuários. Vamos, sei lá, enviar o group, o que eu quero, para a Microsoft assinar. Mas o grande problema aqui é que esses projetos são muito grandes, certo? E tem correções de bugs frequentes, novas funcionalidades que aparecem frequentes, então, cada vez tem uma nova versão surgindo, certo? Então, requisitar a Microsoft para assinar cada nova versão de Gruby ou Kernel não é viável de forma alguma, certo? Então, resolvendo fazer um workaround nessa história, que é usar o Shin. O que é o Shin? O Shin, ele é um mini bootloader cuja única função é carregar o próximo bootloader, certo? Carregar o Gruby. Então, ele é bem simples, ele funciona apenas em UFI, não funciona para o sistema de BIOS antigo, e ele possui um certificado embutido. Quando você build o Shin, você coloca um certificado nele, e no nosso caso, a gente vai colocar o certificado debe lá. Então, o Shin, o código dele é bem pequeno e simples, certo? E as novas modificações e outras versões não são muito frequentes. Então, a ideia é, vamos pedir para a Microsoft assinar só esse pedacinho, só o Shin, e ter o Gruby ou Kernel e todo o resto da cadeia de boot assinado pelo Debian. Então, o nosso novo plano de boot aqui é ter o firmware, certo? Que vai carregar o nosso ShinSignet, que foi assinado pela Microsoft, que vai carregar o nosso GrubSignet, que foi assinado pelo Debian, que vai carregar o Linux, o Kernel do Linux, assinado também pelo Debian. Então, com isso, a gente vai conseguir fazer que o Debian rode nas máquinas de todo mundo out of the box, as pessoas vão poder colocar o cedezinho lá, sem mexer no firmware para poder rodar, ficar menos assustador, não precisa desabilitar o secure boot, e a gente vai ter certeza também, com esse esquema, vamos ter certeza que toda cadeia foi realmente bootada pelo Debian. Se você não considerar o ME e outras coisas de segurança... Perdão? Levantamos? Certo. Então, o que temos hoje? Nós temos já um Shin assinado pela Microsoft, que já está nos repositórios do Debian, está no Unstable. O que não temos, ainda não temos um Gruby assinado pelo Debian, não temos o Linux, e também tem um outro software que se chama firmware update, que precisa ser assinado, porque ele é um outro software para poder fazer update de firmware, que o sistema boot, que está na cadeia de boot também. Pode estar se você estiver fazendo um update de firmware. Ok? Então, vamos falar dos pacotes. Esses pacotes traçam o signage, a gente vai ver o que é. Vamos falar um pouco da infraestrutura do Debian para poder fazer todas essas assinaturas. Então, o que temos hoje? Temos o pacote normal, que tem, geralmente, o nome, o pacote source, o pacote fonte. Tem o nome do pacote, o underlying, a versão. Eu coloquei o ponto de SC lá, só para identificar o que estou me referindo ao pacote source. E, quando você fazer o build desse pacote, vamos ser o pacote.debian lá para uma determinada arquitetura, certo? Por exemplo. Então, a ideia é, além desses pacotes originais, nós vamos ter um outro pacote fonte, outro pacote source, pacote, traço a arquitetura, traço o signage, a underlying, a versão. Então, esse vai ser o nome do nosso pacote, que esse pacote vai ter as assinaturas. E, quando você buildar esse pacote, nós vamos ter um novo pacote.debian, que é a versão do nosso pacote original, só que assinada pelo Debian. Exemplo. No caso do firmware update, versão 10.4, a ideia é ter mais um pacote source, que vai se chamar firmware update, traço a MD64, traço signage. E, quando você buildar esse pacote de traço signage, vamos ter um ponto debe gerado, que vai ter a imagem do firmware update, só que assinado pelo Debian. Ok, então, nesse pacote source, vai ser um negócio novo, não tem ainda no Debian, ele vai conter as assinaturas do arquivo original, do binário original, de forma detachada. Ou seja, vai ser só assinatura ali, pronto para você colar um arquivo original e verificar, certo? Então, quando você buildar esse pacote source, traço signage, o build depende do pacote ponto debe, a versão não assinada, e o build é bem simples, o que ele vai simplesmente fazer é pegar a assinatura, pegar o arquivo original, que está no pacote original, colar a assinatura no arquivo original, e é isso aí, para todos os arquivos que devem ser assinados. E o legal desse esquema é que o build a assinatura não é reproductível, mas como as assinaturas vão fazer parte do pacote source, então você pode buildar quantas vezes você quiser e vai dar o mesmo binário no final, certo? Ok, então o cenário ideal aqui é que o mantenhador mantém apenas um pacote source, ao invés de dois. A gente vai ter dois pacotes source, mas nós queremos que o mantenhador fique assim, certo? Então, a ideia é que esse pacote seja gerado automaticamente para um robô e que esse robô que vai submeter esse pacote de novo para o devem é como se ele fosse um mantenhador, de forma automatizada. Então, vamos falar desse robô, esse robô, na verdade, se chama sign service, é o serviço de assinatura, a gente vai falar um pouco dele e um pouco dessa automação e ele vai funcionar. Então, como ele vai funcionar? Quando o requisitado, quando alguém falar por favor, gera a versão assinada desse pacote, ele vai montar esse novo pacote source simplesmente, submeter assinar o... gerar as assinaturas do pacote original, montar esse pacote source, submeter para o devem e, como eu falei, eles comportam com o mantenhador. A chave dele vai estar dentro lá como se fosse um mantenhador, para ele conseguir submeter diretamente. Antes de a gente avançar, eu vou falar um pouco o que que é o DAQ. Então, o DAQ é o Debian Archive Kit, é o software que é usado pelo FTP Master para poder revisar, aceitar ou rejeitar pacotes. Se você é um mantenhador, quando você submete um pacote, esse pacote está indo para esse sistema que se chama DAQ. Como um Debian Developer, quanto um Debian Mantenha. Então, a ideia é que, quando as pessoas submetem pacotes para o DAQ, alguns pacotes específicos vão gerar um evento de post-accept. Então, o mantenhador viu o seu pacote original, aceitou ele, foi buildado nos BuildDis lá e aquele pacote original está numa listazinha e vai gerar esse evento que vai fazer a requisição para o nosso serviço de assinatura e o nosso robô para gerar a versão assinada desse pacote. Então, só para resumir, tentar deixar claro a dinâmica, geral é, o mantenhador envia o pacote para o DAQ, o DAQ requisita uma assinada desse pacote para o nosso robô o serviço de assinatura e o nosso robô gera esse pacote source, esse segundo pacote source e envia de novo para o DAQ. Certo? Então, vamos falar um pouco de como vai se dar esse empacotamento, como esse robô sabe como gerar esse pacote source. A ideia é que, quando você builda um pacote source você pode gerar dentro de um pacote source, pode gerar múltiplos pacote.dev. Então, ao invés de gerar apenas um pacote.dev vamos gerar no mínimo 2 que é o que a gente já gera atualmente e um pacote template que vai ser usado para esse nosso robô saber como é que gera o source do pacote assinado, certo? E esse pacote template vai ter vários metadados, vai ter uma lista de quais arquivos em quais binários precisam ser assinados, que é basicamente um JSON, vai ter o template do novo pacote, o robô simplesmente vai assinar, copiar e colar para dentro o template, que desde o nosso bypassa. Então, a partir do template, que veio no source geral, quando você buildar o seu pacote source ele vai gerar o ponto.dev normal e o ponto.dev traços template com todas essas metas informações. Então, aqui é um exemplo, quando você fazer o build desse pacote firmware update, ele vai gerar também o traços template, vai gerar o do devs, no mínimo. Bom, aqui é um redundância de novo dois sources e dois binários e vamos ter mais o template, como a gente falou previamente. E aí, então como é a cara desse template, como isso afeta vocês, quem pacota, né? Quando você faz a extração desse template você vai ter um caminho bem especificado, está bem especificado com os barra user, barra share, barra code siren e o nome desse pacote template dentro dessa pasta, vai ter um arquivo que é files.json lá vai listar tudo que precisa ser assinado e qual binário que ele faz parte e o source template, que tem uma estrutura completa da de como tem que ser o pacote source, esse não é o pacote source que o robô vai montar e todas as assinaturas geradas pelo nosso robô tem que ser copiadas pra dentro do source template, barra debian, barra signatures. Então, basicamente, é robô copia das assinaturas pra essa pasta, debian signatures, dá um dpkg traço genchanges pra preparar esse fonte pra gerar o .changes file lá, dá um debsign pra assinar como se ele fosse um antenador e dá um deput pra submeter isso para os archives do debian. E estado atual, né? Tudo. Então, nós temos APIs bem definidas de como o DAQ vai se comunicar como o serviço de assinatura vai pegar todas as informações. Nós já temos pacotes gerando esse esse template ponto debi, que é o chin. Apesar do chin ser assinado, a parte básica do chin ser assinado pela microsoft, o chin tem uns outros serviços ao redor dele, que é um principalmente um mock que é master owner key que tem uma habilidade de você colocar sua própria chave sem ficar procurando, é uma interface única você não fica dependendo de saber onde tá a opção dentro da sua bills lá, certo? E que é pra você poder instalar alguma chave própria e botar um kernel group assinado por você. E o problema disso é que o chin, antes de executar esses outros serviços de boot, ele também verifica se esses outros serviços de boot estão assinados. Então, atualmente o build não é reproductível porque quando você build o chin ele gera uma chave em tempo de build pra poder assinar esses outros pacotes e pra poder botar eles, certo? Então a ideia é, ao invés de uma chave ser gerada em tempo de build porque isso não é reproductível é ter essa chave é ter esses outros pacotes assinados pelo débio então nós já temos essa estrutura para o chin, que ele tem que gerar esses templates também nós temos já o linux kernel gerando os templates, o firmware update gerando os templates e o group 2 é um working progress mas eu acho que tá quase terminado já e praticamente pronto já temos o código do sign-in service do nosso robô que praticamente fui eu que escrevi e mais um ftp master temos a lógica do DAC praticamente pronta e o que a gente precisa fazer então a próxima etapa é fazer deploy de todo esse código começando no experimental e primeiro ir tendo alguém vendo, tudo certinho pra ver se tá tudo ocorrendo bem para o stable ou para o unstable e os outros os outros branches, outros repositórios e é isso que eu tinha pra falar pra vocês perguntas como eu dou fazer um resumo de quais são os requisitos que a Microsoft tem pra assinar as coisas que tornam isso mais complicado quais mais dificuldades pra fazer esse tema todo eu suponho que o requisito de só carregar coisas assinadas venha de requisitos pra assinar o xin como é que isso funciona, quais são os principais problemas certo, então o processo antes, você tá falando assim o que que a Microsoft pede pra falar ok, eu vou assinar o seu o seu binário para o xin especificamente, vou falar mais pro xin eu não sei direitos dos outros antes o processo é mais complicado mas hoje em dia basicamente o processo tá você subimete o seu xin na lista tem uma lista de meio de review de xin o Matthew Garrett e o Peter Jones que são os caras que mantêm o xin enfim, eles têm muito influência que falarem ok, então a Microsoft vai lá assina é basicamente só isso, tipo a Microsoft confia no xin e se os manteres do xin falarem ok ela assina tá bem simples esse processo aí eu já não sei dos outros se você faz assino no group e eu já não sei como é que funciona mas você explica lá um pouco porque a sua organização mas tá basicamente assim, a galera falou ok e a Microsoft assina mais perguntas é uma pergunta meio assim, mas vamos ver se você entende bem, a gente teria que estar pedindo lá para a Microsoft assinar o troço se não fosse o FI e tudo as coisas proprietárias, se a gente usasse um boot livre tinha como fazer uma outra forma se a gente tivesse primeiro se a gente tivesse já uma máquina que vem, porque a ideia aqui é facilitar para o outro usuário, se a gente tivesse uma máquina de fábrica que vem com boot livre seria muito legal, a gente podia essas máquinas podia um vim já com a chave ou podia ter algum esquema de instalar a chave logo no primeiro boot mas aí para facilitar para o usuário a gente depende de que essas coisas vêm de fábrica junto, que seria muito legal se fosse livre uma tentativa de vim de fábrica com essas coisas eu não sei, não sei te dizer eu só acho que de início se tiver também não vai ser muito diferente, porque provavelmente o que aconteceria seria, em vez de ser a chave da Microsoft seria a chave da Dell, então a gente teria que pedir para a Dell assinar de qualquer jeito ou até fazer algum esquema para convencer todas as fábricas de computadores a usar uma chave livre, talvez dê um pouco mais de trabalho quando você fala que o XIN tem uma funcionalidade para você adicionar certificados em uma interface única uma vantagem, como é que eu posso usar essa interface do XIN se eu preciso reassinar o meu próprio XIN eu não teria que usar a interface da própria UFI para adicionar a minha chave e aí, nesse caso como eu estou adicionando a minha chave na UFI eu não preciso do XIN essa interface do XIN é só a partir do leve do XIN para cima mas ele é um wrapper para colocar a coisa na UFI não, eu acho que ele não coloca as coisas no UFI, ele tem uma variável própria você só consegue acessar se você estiver executando em boot service que é em tempo de boot que tem dois modos no boot service você só consegue acessar se você tiver acesso físico a máquina então você está colocando essas informações no XIN, estabilitando o XIN a botar os outros, eu acredito que o XIN não altera a chave que está dentro do firmware é que eu esperava que a assinatura que valida o XIN incluiria dentro do que é verificado pela assinatura incluiria os certificados que o XIN valida porque dessa forma como me parece que você pode adicionar uma nova chave no XIN já assinado pela Microsoft você está transformando o XIN em uma autoridade certificadora a Microsoft está entregando completamente o poder para o XIN sim, mas aí a logica é mesma do firmware você precisa ter a Microsoft confia que o XIN o certificado se você tiver acesso físico na máquina não é para taxas físicos é verdade, obrigado eu sei como isso tem funcionado em serviços de cloud eles costumam ter suporte a secret boot para você carregar coisas assinadas ou só alguns ou nenhum sim, tem eu não sei dizer em detalhes mas eu sei que tem para alguns assim estava pronto já para o bonto, eu sei que tinha gente trabalhando nisso mas basicamente o serviço de cloud eles pegam e colocam a certificada da Microsoft dentro do hypervisor e usa isso aí porque já que é mais global não precisa da pessoa mudar nada mas é uma boa pergunta que eu não sei se os providers se tem a possibilidade de você adicionar a sua própria chave mas isso acho que é novo não é muito divulgado ainda que tem secret boot na cloud eu fiquei em dúvida como funciona essa assinatura do XIN o que que o pessoal manda para a lista é os fontes e o binário e o pessoal verifica que aqueles fontes produzem aquele binário o que exatamente que é assinado o que exatamente é assinado pela Microsoft é o binário do XIN quando você manda para a lista você manda também os fontes e o binário na verdade eu não tenho certeza todas as coisas que você manda agora porque eu não lembro desse processo eu acompanho por fora, por cima mas eu acredito que você mande o fonte binário e os mantenedores do XIN fazem a verificação e se aquilo está ok, eles falam ok a Microsoft assina mas eu não sei te dizer com precisão eu posso pesquisar para você e te responder depois mais perguntas o robô que vai ser o nosso pacote se ele está em desenvolvimento já está quase pronto eu posso te mandar o código inclusive está no salsa no time de GFTV Masters chama Code Trash Signing está tudo escrito o que só falta tem umas detalhes que faltam que nós temos um log para fazer audit log como seria a tradução log de auditoria para a gente logar tudo que a gente assinou e se dá algum pau, talvez a gente dar um revoke dessas assinaturas depois e a gente logar tudo certinho o que já foi assinado algum dia não necessariamente publicado mas que passou para o nosso serviço de assinatura esse log ele está implementado mas tem algumas partes da tabela de estado interna que tem que ser definida mas está praticamente pronto eu diria que a gente já pode começar a colocar no experimento mais perguntas então tá bom gente muito obrigada só antes de terminar eu queria divulgar essa conferência que nós vamos ter em Campinas em agosto e vai ser muito legal a missão da conferência juntar a fazer um ponto de encontro internacional entre os desenvolvedores entusiasos e também a indústria muito próxima é totalmente upstream basicamente assim e a gente queria alavancar aí não só os desenvolvedores brasileiros e também o mercado de upstream do Brasil então vale a pena tem palestras bem interessantes assim, vale a pena então alguns temas que vai ser muito embarca internet of things, cloud tem uma lista lá no site linuxdev-br.net bom gente, muito obrigada aí