Único risco q eu vejo é não se preocupar com dependências ou quebrar o sistema. kk
4 curtidas
Ótimas respostas, porém alguns fatores precisam ser lembrados:
Falhas de segurança e versões de bibliotecas
Com relação à falhas de segurança, quando um programa é empacotado, ele traz toda a linha de dependências dele. Ou seja, uma falha de segurança em uma biblioteca pode estar corrigida no seu sistema, mas se o seu programa SFA (snap/flatpak/appimage) usa uma dependência em versão anterior, a vulnerabilidade ainda estará presente dentro do seu sandbox. Os pacotes da sua distribuição são verificados quanto a isso, de modo que nenhuma vulnerabilidade de alto risco estará presente no seu sistema.
Ao usar um programa SFA, empacotado pelo programador, essa camada de proteção deixa de existir. Também não fica claro quais as dependências foram usadas naquele programa, ou seja, fica difícil até mesmo pesquisar se o seus sistema está em risco!
Atualização de bibliotecas
Quando uma biblioteca apresenta uma vulnerabilidade, a correção é extremamente fácil num sistema modularizado como uma distribuição linux. O pacote é atualizado e todos os seus demais programas já estão seguros. Já nos SFA, cada um dos programas precisa receber a atualização, ser reempacotado pelo programador, e atualizado pelo usuário. Uma cadeia mais longa, com mais chance de falhas, especialmente por conta dos programadores (que além de manter o programa, agora terão que cuidar das atualizações de segurança).
Programas/bibliotecas obsoletos
Uma situação que pode acontecer é o desenvolvedor do programa não estar disposto a atualizar seu programa para a versão mais recente de alguma biblioteca (pois demandaria esforço de readequação de código). Em uma distribuição linux, esse programa sairia do repositório. Porém ficaria fácil para o programador empacotar a versão obsoleta da biblioteca ou mesmo um programa inteiro. O usuário atualiza os pacotes SFA e tem a falsa impressão de estar atualizado.
Conclusão
Ao usar programas snap/flatpak/appimage o usuário deve estar ciente que está deixando de contar com a equipe de segurança da distribuição linux e passando a responsabilidade de correção de falhas de segurança para os programadores dos pacotes snap/flatpak/appimage instalados.
15 curtidas
Tem alguma forma de tornar a abertura dos Snaps mais rápido? Por exemplo, instalei o Spotify em snap e demora uns 20s pra abrir, mesmo em SSD.
1 curtida
Professor Ruksu!! Tudo bem com o senhor?
Muito obrigada pelas informações! Eu já ouvia falado do pamac, mas me havia esquecido o nome dele 
. Também pensava que ele fosse do Arch e não do Manjaro (que é tipo um irmão mais novo do Arch) 
.
Corrigido aqui! Muito obrigada por compartilhar as coisas!!! 
Hum, como estou treinando para usar melhor o terminal, vou estudar com maior atenção o yay também. De fato, parece ser uma ferramenta muito poderosa!
O senhor é show! 
2 curtidas
Oi, tudo bem?
Onde o senhor baixa estes programas de forma segura não sendo do site oficial de snaps? No Github? E como saber se eles já usam este novo algoritmo de compressão?
Muito obrigada pelas informações!
1 curtida
Em algum level todos tem algum risco…mas nada compara com o risco de adicionar um repo ou deb/rpm… no sistema…
7 curtidas
Já tentou a versão flatpak? Aki no meu note com ssd abre rápido.
1 curtida
Ele quis dizer que baixa programas em Snap menores do que aqueles baixados no site oficial (por meio de um pacote .deb, .rpm ou outro).
2 curtidas
Pesquisando um pouco sobre os flatpaks eu achei um comentario interessante do fundador do ElementaryOS
traduzi no google tradutor mesmo:
Flatpak não cria segurança e privacidade perfeitas magicamente. Ele fornece uma maneira executável de tornar as coisas mais seguras e privadas do que são atualmente.
Sim, alguns Flatpaks estão sendo distribuídos com sandboxing nada perfeito. O Firefox Flatpak por padrão atualmente pode acessar sua pasta Downloads. Mas o pacote Debian já pode acessar qualquer coisa em seu diretório home. Portanto, embora não seja perfeitamente confinado, o Flatpak é uma grande melhoria. E, se desejar, você pode escolher ajustar a sandbox Flatpak de acordo com sua preferência. Você pode até proibir o acesso do Firefox à Internet. Isso não é possível com o pacote deb atual.
Alguns controles remotos podem não ter boas políticas de segurança. Mas você também já tem esse problema com os gerenciadores de pacotes tradicionais. Veja todo o escrutínio que o Mint enfrentou sobre sua política de segurança. Toneladas de pessoas adicionam PPAs hoje sem pensar duas vezes em sua política de segurança. Não há nada sobre o formato que decida isso. Depende de você certificar-se de que confia nas fontes de seus pacotes. Este é um grande motivo pelo qual é sempre aconselhável limitar-se às fontes de software que vêm com sua distribuição.
Cada pacote Debian que você já instalou tem permissão de root no momento da instalação. E pacotes populares (como o Chrome) exploram esse fato regularmente para fazer modificações no sistema host. Isso nunca será corrigido para pacotes Debian porque faz parte de seu design. É por isso que Mark Shuttleworth apontou anos atrás que você efetivamente dá root para cada mantenedor de cada PPA que você adiciona ao seu sistema. O exploit do qual o autor se queixa foi corrigido há quase 3 anos em Flatpak. Pacotes Flatpak e mantenedores que distribuem flatpaks não têm permissões de root em seu sistema por design.
10 curtidas
resposta sobre Flatkill
"Flatpak é o futuro …
… e ainda é um trabalho em andamento. Eu uso muitos aplicativos através do Flatpak como colaborador do projeto, mas não todos. Nem todos os aplicativos funcionam bem e às vezes você deve aceitar que, sem um retrabalho sério, você não pode ter todos os aplicativos empacotados em um flatpak. Portanto, funciona melhor para alguns aplicativos do que para outros, e às vezes eu honestamente recomendo as versões não flatpak em vez da versão flatpak.
Um ponto que o autor de Flatkill (que é anônimo) martela é, às vezes, a falta de sandbox. Isso é correto, há dois motivos pelos quais às vezes o software vem com sandboxes tolerantes.
-
A isenção 1 é a compatibilidade retroativa com aplicativos antigos. Às vezes, você quer um extrator de CD como o Asunder, mas precisa aceitar que o Asunder não funcionará bem enquanto estiver em uma área restrita. Esforços estão sendo feitos para melhorar a situação, mas “temos que renovar enquanto mantemos o negócio”.
-
A isenção 2 são ferramentas de desenvolvimento. Se você compilar e construir software, presumimos que você tenha a habilidade e o conhecimento necessários para não executar um ataque de ransomware em sua própria máquina. O exemplo dado é o Octave, uma ferramenta avançada do tipo Matlab. Se você escrever seu próprio script Octave para criptografar suas fotos, isso depende de você.
Talvez também seja bom destacar que todos os ataques mencionados no post, já funcionam com pacotes RPM e DEB. Flatpak não é totalmente seguro … é mais seguro. Se os mantenedores do Flatpak quiserem atacar você, eles podem.
O mesmo para Flatpak quebrando algumas integrações de desktop … Vocês sabem que todo aplicativo executado como um usuário pode ver todos e todos os arquivos e processos desse usuário? Sim, o kernel sandboxes os aplicativos em uma extensão, mas apenas no nível do sistema. Flatpak quebra algumas integrações para impedir que isso aconteça.
Se o Android e o IOS fizeram algo bom para o campo da ciência da computação, é que você não deve presumir a boa fé de todos os aplicativos que os usuários executam. Flatpak é a resposta para essa compreensão.
Existe uma alternativa séria …
… e é um jardim murado (Snapcraft). Flatpak começou como um balcão contra o jardim murado que a Canonical está construindo, chamado Snap. Embora o código do cliente do Snap seja de código aberto, o sistema é projetado de forma a servir apenas a um mestre. O risco de ter uma parte controlando a distribuição de todo um cenário de software é muito sério. Flatpak é uma resposta direta à ameaça do movimento monopolista da Canonical.
A menos que você queira que a história se repita … olhando para o enorme duopólio dos smartphones e o iminente duopólio do desktop, é importante investir no Flatpak. É por isso que o chamamos de sistema de embalagem para o futuro, e não o presente.
Conclusão
ISSO É MEDO, INCERTEZA E DÚVIDA"
6 curtidas
Até dá pra corrigir sem alterar, só não é de interesse dos devs, basta colocar o próprio dpkg em sandbox
O detalhe que nínguem observa, é que se eu posso usar o Octave via flatpak para encriptar coisas, é possível um app intencionalmente malicioso que faça isso sem depender do usuário, via de regra isso acontece porque o flatpak (na verdade o bwrap) são tapa buracos para algo que nasceu quebrado por design: a forma como apps lidam com arquivos (e isso afeta todos os sistemas operacionais desktop em igual escala), cada app é um gestor de arquivos em potencial, eles podem manipular apps que o usuário não deu autorização, um exemplo fictício:
- Um editor de textos chamado ACME Editor
- Usuário abre o arquivo “teste.txt” com ACME Editor
- ACME Editor sabe que o usuário quer alterar apenas “teste.txt” porém, ele pode deliberadamente alterar todos os arquivos ao menos na pasta onde “teste.txt” está, podendo inclusive criar outros arquivos
Em um mundo ideal, ACME Editor só deveria ter acesso e alterar a “teste.txt” e pedir permissão para criar novos arquivos, curiosamente os portals tem essa função porém não é usada
O ponto do flatkill.org não é se a falha foi ou não corrigida, eles inclusive mencionam a correção, o ponto é a forma como trataram a correção
4 curtidas
Não sou especialista na área, então me corrija se estiver errado
Esta informação me parece um tanto quanto sensacionalista, mas confesso que não conheço em detalhes, então pode estar correta. Então poderia fornecer a fonte desta informação, de preferência do ponto de vista técnico? Ou da empresa explicando como funciona?
Não vejo um pacote ser feito pelo desenvolvedor (mesmo que conhecido) como sendo algo que leve as chances de ser malicioso tendendo a zero.
- Um AppImage de cógido fechado (e aberto também) ainda pode, se assim configurado, ter acesso as informações do usuário e mandar pra onde quiser, ou modificá-las.
- Como a distribuição vai de cada desenvolvedor, um site de download pode ter políticas de segurança mais frágeis que outros, podendo esses casos serem mais facilmente hackeados e distribuir versões maliciosas de seus apps.
- Para um usuário leigo, buscar um app em diversos locais, pode levá-lo a baixar em um site que se diz ser o original, mas é uma imitação com o código do app modificado
- Para o usuário ter acesso a atualizações de um AppImage, o desenvolvedor do app tem que ter embutido esta funcionalidade ou o próprio usuário tem que instalar por conta própria um programa que faz esta busca e atualiza. Se não o fizer, estará sempre rodando uma versão desatualizada de um aplicativo em que uma vulnerabilidade pode já ter sido corrigida
- A SENSAÇÃO de ser mais seguro é uma característica pessoal e não técnica. Então depende da cultura de segurança da pessoa. A mesma frase pode-se aplicar a qualquer formato. Eu, por exemplo, quando vejo que não utilizo a função de acessar a internet de um app, eu bloqueio este acesso. Da mesma forma acesso aos meus arquivos. A questão é que o formato permite ter esse controle facilmente.
- Por design, o flatpak não consegue rodar em modo root, então um código malicioso pode ser rodado somente dentro do nível de usuário comum.
- AppImage, até onde sei também roda em nível de usuário comum. Nunca tentei ou ouvi falar em rodar em modo super usuário.
- Me corrija se tiver errado, mas pelo fato do snap PODER ser rodado em modo root, daria a possibilidade também de alterar arquivos do sistema.
- Da mesma forma que existem recursos do snap que não são utilizados por todos os apps, existem também no flatpak. Existe uma funcionalidade do flatpak que se chama portais, que na questão de acesso aos arquivos, o app solicita ao usuário escolher o arquivo em que terá acesso. Neste caso, o app somente terá acesso ao arquivo depois de escolhido pelo usuário e somente enquanto a interação com este estiver acontecendo. Se o programa for reiniciado, por exemplo, este acesso não existirá mais.
Não pesquisei ainda o suficiente sobre o assunto. Mas pelo que pude perceber:
- Os apps são construídos em cima de runtimes. Quando as runtimes aplicam atualizações de segurança, cabe ao desenvolvedor fazer a atualização do seu app para funcionar em cima desta nova versão.
- Quando um app utiliza uma runtime de versão desatualizada, uma mensagem, durante a atualização dos programas, é passada ao usuário informando para entrar em contato com o desenvolvedor para sua atualização.
5 curtidas
Pra isto servem os portais junto com o gerenciamento de permissões, que citei anteriormente, para permitir que o app não tenha acesso a arquivos ou funcionalidades que não precisariam. O fato dele não ser obrigatório, creio que seja por motivo de adaptação. Como você mesmo citou, como as coisas sempre funcionavam desta maneira, produzir um formato que mude radicalmente como as coisas funcionam sem dar uma opção de adaptação, dificultaria demais a adoção do formato. Quem sabe futuramente as plataformas de distribuições, flathub principalmente, não decidam tornar isto um requisito?
4 curtidas
É uma característica do AppArmor nesse post tem uma explicação simples de entender e com as referências, se quiser pesquisar por conta, veja sobre “how AppArmor works”
Marquei aqui mas a ideia é responder os tópicos, nesse caso você fugiu totalmente do escopo (ponto 4), AppImages são gerados em ambientes de integração ridiculamente seguros sendo geralmente GitHub Actions e Travis CI (cuja segurança é atestada por big companies como Google, Microsoft, Yahoo… eles me parecem entender do assunto) continua e a hash sha265 do arquivo não é diferente em nenhum dos quase 1200 AppImages indexaveis pelo Google Search (ponto 2).
Sim e isso é ponto neutro entre Flatpaks e AppImages e empacotamento nativo, só snaps tem alguma proteção sobre e ainda não é tão eficiente dependendo do ataque, logo não faz sentido elencar isso (ponto 1)
E o 4 é um trade off, novamente apenas snaps possuem um sistema automatizado de atualização, ambos Flatpaks e AppImage dependem (e devem depender) de uma intervenção do usuário, outro ponto neutro para ambos os lados, ter um mecanismo de atualizações, não significa nem que o usuário vai atualizar (a menos que seja forçado a isso) nem que o app vai de fato atualizar, lembrando que a esmagadora maioria dos Flatpaks é feita por usuários do flatpak e não pelos devs, alguns até tem commits do dev no builder mas geralmente se resumem a links de onde obter recursos, sendo assim é meio inútil ter um sistema de atualização que:
-
O user pode optar por não atualizar por n período de tempo
-
O desenvolvedor não presta suporte direto ao formato de forma on release, falhas graves de segurança e usabilidade demoraram a chegar no Flathub por isso
(Último ponto)
Então comparando os dois temos o seguinte cenário: O AppImage tem as atualizações de segurança porém o usuário tem que ir atrás pra atualizar, o Flatpak tem o mecanismo para atualizar, porém não tem (ou tem com atraso) na maioria dos casos atualizações de segurança
Sim, exatamente isso, o Flatpak cria uma brecha humana eu falo isso:
Utilizador = usuário, que em tese não deveria ser techsaviness (ser um usuário técnico)
E ainda depende de conhecimento técnico
Curiosamente eu disse logo abaixo:
Ou seja, eu sei que existem portais, eu sei que eles tem essa capacidade, porém os empacotadores do Flatpak usam geralmente o acesso ao filesystem
A correção em questão foi referenciada na época como “This is a minor security update” sem maiores descrições, uma falha que permitia acesso root ao sistema foi tratada como algo pequeno, esse foi o ponto em questão
Na verdade não existe esss barreira, ao funcionar da forma como Android faz por exemplo “Permitir ler e escrever em um arquivo” e “Permitir ler e escrever no diretório onde o arquivo estar” sendo isso invisível ao aplicativo, resolveria
4 curtidas
Bem, @Natanael.755, alguns argumentos eu concordo e outros possuo contra argumentos, mas sinceramente tô vendo que continuar esta conversa vai levar muito mais tempo do que tenho disponível. Portanto, sugiro a autora da pergunta @Ana_Paula:
- Verificar nos sites oficiais de cada solução sobre a questão de segurança
- Caso queira se aprofundar em alguma tecnologia em específico, verificar em sites oficiais e especializados.
- Se ainda tiver dúvida, perguntar diretamente aos desenvolvedores destas plataformas e especialistas. Eles saberão expor melhor os pontos fortes e fracos de cada uma
- Fique atenta que nenhuma destas soluções é perfeita e cuidado com argumentos que afirmam isto
- Não se baseie somente em comentário de pessoas aleatórias (me incluindo) em um fórum. Fórum é um local onde cada um coloca informação sem necessitar de checagem de dados, sobre qualquer tema. Então, faça sua pesquisa
8 curtidas
Para mim, como leigo ─ e portanto, sem entrar nos vários detalhes técnicos destrinchados pelos colegas ─ esse é o ponto fundamental.
«Viver é muito perigoso». Nada é 100% seguro nessa vida.
Mas um dos pontos altos do Linux é que a comunidade está sempre usando, testando, verificando, apontando possíveis falhas, e os nerds em geral e os desenvolvedores de cada pacote vão lá no código, tornam a examinar etc.
Existe nisso alguma “coordenação”, certa transparência etc.
Isso, nos Kernels e ferramentas básicas “ativos” ─ assim como nos aplicativos de uso geral ─ e nos repositórios de cada distro, onde se mantém a consistência do conjunto, conforme as versões incluídas, monitoradas e mantidas (suporte, correções).
A profusão de ofertas apetitosas lembra o velho conselho dado às crianças para ter cuidado com quem oferece balinhas e doces ─ que no mundo do software equivale aos “baixaki” da vida.
Anos antes de abandonar de vez o Windows, eu já me havia acostumado a evitar programas encontrados na internet, e com isso me desacostumei de precisar “formatar e reinstalar”. No Linux, sempre evitei PPAs no Kubuntu, Mint, KDE Neon (se cheguei a usar 3 foi muito, e por pouquíssimo tempo). No openSUSE, no Fedora, no Mageia, habilito o mínimo de repositórios fora dos “oficiais”. No Arch, uso o mínimo do AUR. Em todos, ainda não comecei a usar AppImage, nem Flatpak, e muito menos Snap2. ─ Este último é o que gosto menos, embora não por motivos técnicos minuciosos, mas por aspectos no seu “entorno”, inclusive o histórico da Canonical. ─ Com esses cuidados (entre outros), há anos não “perco” um sistema instalado. O Debian testing, o openSUSE etc. duraram 3 anos sem acidentes, e depois disso só precisei reinstalar quando mudei de computador.
No momento, meus grandes furos a essa “regra” são o GoogleEarth, o Chrome (em várias distros em que o Chromium perdeu a sincronização), no Arch 1 pacote do AUR. ─ Pelo que os colegas comentaram até agora, Chrome seria um perigo. Ok, vou pesquisar sobre o AppArmor.
Sou meio cético, quando vejo falar de brechas de segurança. Quando se descobre 1 e se corrige, parece haver uma corrida maluca, um alarme geral, e reitera-se que é preciso estar sempre atualizando, de hora em hora etc. Para isso contribui muito a necessidade dos blogs de atrair visitantes o tempo todo, bem como a ansiedade de muitos colegas em “ser o primeiro a compartilhar” etc. ─ Na verdade, tais brechas existiram durante anos, décadas, e a correção pode muito bem esperar o final da semana, quando atualizo todas as distros manualmente.
O grande “perigo” que vejo nos AFS (prefiro botar o Snap2 no final he he) é a dissolução da “comunidade”. Cada potencial desenvolvedor que vê neles uma possibilidade de ganhos imediatos, de certo modo, se desliga do esforço comum, na medida em que passa a dedicar seu tempo a um esforço individual. Em certa medida, de contribuidor passa a predador.
Depois daquele ótimo tutorial do @Rodrigo_Chile, comecei a pensar em instalar o Manjaro (em dualboot) para brincar mais com o AUR, Flatpak etc. ─ sem afetar minhas outras distros, que preservo como ferramentas valiosas. ─ Com o que está funcionando, não faço experiências malucas. ─ Também por isso, sempre mantive pelo menos 2 distros em dualboot (e agora várias: é divertido). No momento, Debian testing, Fedora, Mageia e Arch Linux são as que me servem melhor, no que se refere às ferramentas de que preciso no dia-a-dia. VMs não me dariam 3 alternativas em caso de falha da distro “principal”.
7 curtidas
Olá @realgrm !
Sim, estou acompanhando com calma todas as colocações. Foram excelentes explicações e me fazem pensar para além de snaps, flatpaks e appimage. Linux te dá liberdade, mas liberdade é responsabilidade. Entendo agora que foi por usar está responsabilidade mas não ponderar sobre minhas responsabilidades (e agir com desconhecimento), que me levaram e ainda me levam a ter problemas com o uso de meu computador.
Temos escolhas e escolhas tem consequências boas e ruins. É necessário saber refletir sobre estas escolhas. Isso se expande para além da informática… Quanto mais informação e opções de escolha melhor, mas também é necessário saber desenvolver um pensamento crítico a respeito da informação, desenvolver uma curadoria própria e isso se atinge com o desenvolvimento de conhecimento.
Enfim, é muita coisa por se aprender ainda e refletindo graças aos compartilhamentos de todos vocês, vejo que fiquei em uma posição defensiva quanto minha aprendizagem… É difícil, sim, é muito, mas com esforço e respeitando o próprio tempo de aprendizagem (se conhecendo e reconhecendo minhas limitações) é possível sim aprender. Talvez não dominar o sistema de ponta a ponta e tudo que é conteúdo envolvendo Linux, mas usar de forma cada vez mais eficiente (e segura) o sistema.
Hoje reflito mais antes de apertar um botão ou digitar um comando de instalação e devo agradecer e muito a vocês por tudo isso!
Como diria um antigo chefe meu: “o problema talvez esteja naquela pecinha na frente da tela e do teclado…”
Muito, muito, muito, muito obrigada por tudo pessoal. Me sinto muito mais confiante em aprender!
Ps.: Agradecimento especial ao @Rodrigo_Chile até mensagem em privado enviei ao coitado para tirar dúvidas. 
9 curtidas
@Ana_Paula,
Parabéns pela humildade e pela busca do conhecimento
@frc_kde,
Bem, continuo sem tempo, mas como eu vi que seu comentário bate com o tema flatpak que estou pesquisando tecnicamente ultimamente, e para me ajudar a fixar meus estudos, vou gastá-lo mesmo assim. E como estou pesquisando particularmente sobre flatpak, não posso opinar sobre os outros 2.
Se o sua preocupação é comunidade, dá uma olhada neste app que escolhi de forma aleatória na flathub, de código aberto, o Bottles:
Contribuidores do Bottles (Publisher): Esta é a lista de todos que todos os que contribuíram para o Bottles estar disponível no flathub, escrevendo, entre outros, o manifest. Neste caso, é realizado por uma comunidade
Manifest do Bottles: É onde ficam as informações para “montar” o aplicativo, são ditadas quais permissões o app terá por padrão, o que é diretamente ligado a questões de privacidade e segurança que são liberados ao app.
Também é incluso quais runtimes ele usará. Runtimes são onde o aplicativo tira suas dependências básicas e é montado a partir dela. Neste caso ele usa a runtime abaixo e que também é montada em comunidade, o que inclui assuntos de segurança de todos os apps que usarão a mesma base.
app-id: com.usebottles.bottles
runtime: org.gnome.Platform
runtime-version: '40'
sdk: org.gnome.Sdk
Ainda dentro do manifest, mas com foco na parte grifada abaixo, dá pra perceber que, o programa é montado a partir do repositório do próprio projeto no GitHub, onde a comunidade foca nas questões específicas do aplicativo, o que inclui a parte de segurança específica do app.
modules:
[...]
- name: bottles
[...]
sources:
- type: git
url: https://github.com/bottlesdevs/Bottles
tag: 3.1.5
Se quiser verificar outro aplicativo do flathub, o caminho é https://github.com/flathub/[ID do aplicativo]. Informações das demais runtimes está aqui.
Enfim, antes era quase que regra a verificação e adaptação de um repertório de apps pelos desenvolvedores de cada distribuição para uso na própria distribuição (e talvez derivados). Hoje elas tem a opção de embarcar com aplicações flatpak e focar no próprio OS, incluindo sua segurança. E se ainda se interessarem em manter aplicativos, suas contribuições servirão para toda a comunidade de uma vez.
Aff, gastei bem mais tempo do que pensei e deveria. Agora vou sair desta discussão.
5 curtidas
Eu baixo na Snap Store. Vários programas são disponibilizados na Snap Store pelos próprios desenvolvedores, mas há também aqueles pacotes disponibilizados por terceiros e esses nem sempre são bem empacotados.
1 curtida