Bug#868486: diffoscope often fails to detect APKs

[Hans-Christoph Steiner]

The APK format is a ZIP file that always includes the files
AndroidManifest.xml and classes.dex.  Then it also always
has a JAR signature (i.e. META-INF/).  It does not have the
JAR magic number CAFEBABE in it.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Горещи намаления в Offex.bg!

[Office Express]

Ако не
виждате добре писмото или не работят
линковете, моля натиснете ТУК, за да го отворите в
Интернет.














ОФИС СТОЛОВЕ Виж всички в промоция ТУК














КОПИРНА ХАРТИЯ Виж всички в промоция ТУК





АРХИВИРАНЕ И СЪХРАНЕНИЕ
Виж всички в промоция ТУК





КАНЦЕЛАРСКИ МАТЕРИАЛИ Виж всички в промоция ТУК











КАФЕ ПАУЗА Виж всички в промоция ТУК





ХИГИЕНА Виж всички в промоция ТУК











ОФИС МЕБЕЛИ Виж всички в промоция ТУК




















ОФИС ТЕХНИКА Виж всички в промоция ТУК











 3 години Програма за лоялност - над
500 000 раздадени БЕЗПЛАТНИ подаръци!
Събирайте точки и вземете своя подарък
по избор.   







Разгледайте всички подаръци
ТУК









Промоцията е валидна до
31.07.2017 година или до изчерпване на
наличностите. Всички цени са без ДДС.
Важи само при плащане в
брой или авансово по банков път.Отстъпките са
валидни само при покупка от електронния
магазин www.offex.bg.Доставка
според Логистичната
карта на Офис Експрес. Виж тук. БЕЗПЛАТНА
ДОСТАВКА* за всички поръчки над 49 лева
без ДДС за Зона 1,2,3 и над 99 лева за Зона 4.
Всички останали поръчки са за сметка на
клиента по специална тарифа на Експресо
или Спиди.  *
Безплатната доставка не важи за: мебели,
столове, метални шкафове, сейфове,
извънгабаритни изделия: бели дъски,
екрани, градинска и мека мебел.
Информация за стойността на доставката е
посочена в описанието на продукта в
сайта или се договаря допълнително. Офис Експрес не доставя до
адрес поръчки под 29 лв. без ДДС. Тези
поръчки можете да вземете от склад
София.Посочените цени са без ДДС, с
начислена отстъпка. Количествата са
ограничени!Office Express не
носи отговорност за допуснати печатни
грешки!








Съгласно Закона за
Електронната Търговия Ви информираме, че
това може да е непоискано търговско
съобщение. Вие може да го приемете или
отхвърлите. Получавате това писмо,
защото присъствате в базата данни на Office
Express. Ако не желаете да
получавате информация, моля ОТПИШЕТЕ
СЕ ОТ ТУК и ще преустановим
изпращането на търговски съобщения към
Вашата компания.Ако сме Ви
обезпокоили, моля да ни извините! 











  

  

  

  

  



  

  



  



  



  





  







  







  



  







  



  





  





  

  

  

  



  

  





  





  

  

  

 




___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: About compile randomness for clojire or antlr

[William Zhou]

> Thanks for replying.
>Yes, the code using antlr is for generating parser.
>Actually we are using apache hive and  apache storm, and antlr code I said 
> is in hive（e.g. HiveParser.g） and clojure code is in storm（e.g. config.clj）.
>Is this kind of problem solvable？
> 
> Regards,

From William Zhou

> 在 2017年7月24日，15:38，Chris Lamb  写道：
> 
> Hi William,
> 
>> these code were compiled into different bytecode every time. the
>> randomness are from some ordering problem for variable definitions
>> or instruction sequences when i using javap to disassemble the class.
> 
> First, is the code in question a parser generator? If so, those often
> result in non-deterministic output as they often iterate over hashes
> etc. in their output.
> 
> However, if it's not we have seen this in entirely "static" code:
> 
>  
> https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_java_bytecode_issue.html
> 
> … and, as the page mentions, we don't know why it happens. Can you spot
> anything perculiar about those packages? (eg. do they all use Clojure;
> could it be that...?)
> 
> 
> Regards,
> 
> -- 
>  ,''`.
> : :'  : Chris Lamb, Debian Project Leader
> `. `'`  la...@debian.org / chris-lamb.co.uk
>   `-
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

От любов към продажбите - част 1

[Тренинг]

Здравейте,

Включете се към
лятното издание на тренинга Виртуоз в
продажбите и научете виртуозни техники
за успешни продажби.

Виртуоз в продажбите – част
първа

Пет стъпки за
продажба + две за виртуозни
търговци

Яснота, разбиране и
практика извън границите на
стандарта

В днешния търговски
свят, бизнесът харчи прекалено много за
маркетинг, транспорт, офиси, свързани
разходи за обеди, вечери и какво ли още
не. Когато прибавим към това заплатите,
бонус схемите и времето прекарано в
срещи, търговските ни умения се
превръщат в най-ценния актив, от който
зависи дали бизнеса ни ще расте или ще се
свива.
Тренингът „Виртуоз в
продажбите“ ще Ви помогне да
прескочите опцията „добър
търговец“, ще Ви даде инструменти с
които всеки ден да развивате уменията
си!
Този тренинг е  създаден от
Георги Христулев изцяло чрез
методологията УЧЕНЕ ЧРЕЗ ПРЕЖИВЯВАНЕ и
съдържа най-ефективните техники от НЛП,
коучинг и медиация.
Важно е да се каже, че правилните
думи са тренинг и коучинг, а не тийчинг и
лърнинг, тъй като ние заедно ще тренираме
и развиваме уменията в среда подходяща
за това.

За
треньора:
Кой е Георги
Христулев? SalesCoach, NLP мастер практик,
медиатор, управител на маркетингова и
дигитална агенция „Уеб Дайрект“
ЕООД, съдружник в счетоводна компания
„QBS“, управител на „Агенция за
право и финанси“ ООД.
Може да разберете повече за
Георги Христулев, като потърсите
резултати за него в Google. Също може да
прочетете, какво казват курсисти
завършили тренинга от страницата във
Facebook https://www.facebook.com/salescoach.bg
Вижте препоръки
от участници, които са били на този
тренинг:
- препоръка от Таня
Илиева "Евроконсулта"ЕООД;

- препоръка от Павел
Хрисков "Интелексис" ООД;

- препоръка от Георги
Чешмеджиев "Телепол"ЕООД;

- видео
материал от участници и много
др. може да разгледате от страницата във
фейсбук.


Дати на
провеждане: 4 и 5 август (петък
и събота)

Час: на 4ти от 10 - 18ч; на 5ти от 10 - 15
ч.

Място: София, зала Лозенец,
ул. Бисер 2 (близо до НДК)

Цялата програма изтеглете от тук:


Цена: 180 лв. до 29 Юли,  вместо 240
лв. (спестявате 60 лв.)

Цена за двама и повече от една
фирма х 160 лв. за участник (спестявате 80
лв. на човек)

За да запазите място моля обадете се
на Ралица на телефон 0878 161 907 

За въпроси свързани с програмата на
обучение може да се обадите и на Георги
на телефон 0878 161 901


*Важно: на 25
и 26 август (петък и събота) ще се проведе
част втора на тренинга. Попитайте Ралица
за свободни места и условия за
закупуване и на двете нива!


П.С. Виртуоз означава: Майстор, който
владее техниката по изумителен начин и
се отличава от останалите майстори със
своята уникалност.

Каня Ви да откриете и развивате
своята виртуозност в
продажбите!

Обадете се на Ралица
още сега на 0878 161 907, местата в залата са
ограничени до 21. Вземете преднина
запишете се на 0878 161 907.

П.С. Стандарта за
добри постижения в продажбите е 20/4/1. Това
означава; 20 обаждания, 4 срещи, 1 продажба.
Курсисти преминали тренинга споделят
резултати 20 /8 /3. Ефективната комуникация
е гарантиран успех в продажбите. Вземете
преднина, обадете на Ралица още сега на
0878 161 907 и запазете своето място.

За допълнителна
информация се обадете на 0878
161 907










   
      Съгласно закона за
електронна търговия Чл. 6, ал. 1 Ви
уведомяваме, че е възможно това да е
непоискано търговско съобщение. То е
еднократно изпратено писмо до Вашия e-mail
адрес, който е взет от публичното
пространство. Извиняваме се, ако по
някаква причина сме Ви притеснили с
нашето предложение. Ако не желаете да
получавате съобщения от "Sales
Coach", моля натиснете ОТПИСВАНЕ за
да се откажете да получавате нашите
бюлетини!
 





___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Use of .buildinfo in buster

[Adrian Bunk]

On Mon, Jul 24, 2017 at 09:46:27PM +0100, Chris Lamb wrote:
>...
> Related to this is how we show/expose reproducibility to end users, if it
> all. Some discussion of sorts is happening on #863622 (src:apt).
>...

How is this supposed to work for DSAs?
Do you want to claim a security update is reproducible without checking,
or do you want to delay DSAs until the packages have been reproduced 
for all architectures?

Why should this be a per-package user-visible issue instead of aiming
at giving guarantess for all packages in main?

There is also a certain amount of WTF:
This would make a relatively hard to exploit issue appear more
worrisome to a user than installing a browser engine with zero
security support and more than 100 unfixed CVEs.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Status update from the Reproducible Builds project

[Adrian Bunk]

>...
> Debian Policy
> =
> 
> We are in the process of making reproducibility of packages something
> properly documented in policy.  Writing patches for policy is not easy,
> so we welcome input from everyone to be able to better consider all the
> needed facets.  See bug #844431 [16] for it.
> Also, we wish to remind everyone that Debian Policy aims at documenting
> current practices, it's not a "stick" to impose new rules.  That said,
> we believe reproducible builds to be among the best practices today.
>...

If it could be interpreted in the future to include things that are
not current practice today, it would be a stick to impose new rules.

The main problem is the lack of an exact definition what
"packages build in a reproducible manner" includes, and what not.

Bill already explained that "it is possible to reproduce" is a much 
easier problem to solve than "it will always be reproduced".

I would suggest a top-down approach to that:

What are the high-level guarantees reproducible builds plans to make 
for all packages in buster?

What exactly is required from every single package for that,
and also realistic to achieve for buster?

Once you have these plus a list of all remaining bugs, you can
go to the release team asking whether these can be considered
as release critical for buster.

At that point documenting this status quo for policy should
be straightforward.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#866120: diffoscope: please add an xml comparator

[Chris Lamb]

Hi Juliana,

> Just found out what was going wrong.
> 
> XMLFile returns an array with the Difference object, while the
> previous TextFile class doesn't. So test_apk was looking for a
> unified_diff in the wrong place.

Neat — looking forward to your patch! In fact, can you commit it
directly? :)

> This is easily fixed, but I've got a new question. Since XMLFile
> now returns an array, the presenter displays the difference for
> AndroidManifest file with two column pipes instead of one.
> (https://paste.debian.net/977967/)

I guess my first question would be whether other comparators that do
similar pretty-printing / decoding do the same thing, eg. JSON, etc.
etc.?


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Use of .buildinfo in buster

[Adrian Bunk]

On Sun, Jul 23, 2017 at 01:54:32PM +0200, Mattia Rizzolo wrote:
>...
> Buildinfo files
> ===
> 
> We have been playing with .buildinfo files [9] for more than two years,
> and dpkg finally started producing them with version 1.18.11 (Nov 2016).
> 
> Some weeks later dak started to store those files, and they are
> accessible to all DDs in
> mirror.ftp-master.debian.org:/srv/ftp-master.debian.org/buildinfo.
> There are 214791 unique .buildifo files at the time of writing.
> 
> Our dreams for those files do not end there, however; we want those
> files be published and much more.  You can see in [10] more details
> on these files as we thought of them, and the current format as
> implemented by dpkg is available in deb-buildinfo(5) [11].
> 
> We are currently blocked awaiting feedback from ftp-masters on this (see
> #763822 [12]).  Please consider helping out if you can!
> 
> We also have a proof of concept website reachable at
> https://buildinfo.debian.net that is aiming to collect .buildinfo files
> coming from everywhere; currently only our CI is systematically pushing
> .buildinfo files there, but there is another open bug for ftp-master to
> push the .buildinfo of officially built packages there as well (see
> #862073 [13]).  Also note that the service is open to anyone without
> authentication (by design), so everybody could push their own .buildinfo
> file with a simple HTTP POST.
>...

What and how is expected to work based on .buildinfo files in buster?

Usecases based on .buildinfo files uploaded by random people are more
on the fringe side, a more relevant topic is how users can get the 
.buildinfo files from the binaries they are using (or plan to use).

What tool(s) in buster will allow users to download the .buildinfo files 
matching the packages they are using and what is the canonical location 
where such tools will download them from (Debian mirrors or
buildinfo.debian.net)?

If wide adoption of .buildinfo is desired, will providing and 
downloading .buildinfo also seamlessly work for local repositories
in cases where the .buildinfo must not leak to a public place?

Is the sig-repos infrastructure expected to be available for buster,
and how would that interact for example with security updates installed
through unattended-upgrades?

Likely none of the above has an answer right now, and that is OK.
My point is that these are topics that have to be started soon
if it shouldn't be too late for buster.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#866120: diffoscope: please add an xml comparator

[Juliana Rodrigues]

Hi Mattia,

Actually I havent. Looks like minidom is vulnerable to both
[billion laughs] and [quadratic blowup].

Should we migrate to defusexml? What you think? (:



2017-07-21 14:22 GMT-03:00 Mattia Rizzolo :

> On Fri, Jul 21, 2017 at 10:48:07AM +0100, Chris Lamb wrote:
> > … And I've now also merged the code into our Git repo. Thanks!
>
> Did you both go through
> https://docs.python.org/3/library/xml.html#xml-vulnerabilities and
> decided that the standard minidom was safe for our usages?
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#866120: diffoscope: please add an xml comparator

[Juliana Rodrigues]

Hey Chris,

Just found out what was going wrong.

XMLFile returns an array with the Difference object, while the
previous TextFile class doesn't. So test_apk was looking for a
unified_diff in the wrong place.

This is easily fixed, but I've got a new question. Since XMLFile
now returns an array, the presenter displays the difference for
AndroidManifest file with two column pipes instead of one.
(https://paste.debian.net/977967/)

Should this be fixed or its the expected behavior?

Thanks!

2017-07-24 7:32 GMT-03:00 Chris Lamb :

> Hey Juliana,
>
> > Yes! I would like to work on fixing that. Also, I'll take a look at the
> > other failed tests and get back at you. (:
>
> Any news on this? We'd love to get the tests all passing again :)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb, Debian Project Leader
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Please review the draft for week 117's blog post

[Ximin Luo]

Hi all,

This week's blog post draft is available for review:

https://reproducible.alioth.debian.org/blog/drafts/117/

Feel free to commit fixes directly to drafts/117.mdwn in

https://anonscm.debian.org/git/reproducible/blog.git/

I'll wait at least 24 hours from the time of this email for any comments, and 
if everything is good then I will publish it soon after that.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#868486: diffoscope often fails to detect APKs

[Ximin Luo]

Control: tags -1 - pending

Hans-Christoph Steiner:
> [..]
> 
> I'd like a way to force the file type in diffoscope.   We are calling it
> from a build process, so we already know all files are going to be APKs.
> Also,  I tried to get this added to libfile, but upstream is not willing
> to accept detection routines that rely on more complicated things like
> presence of a file in a ZIP. They just want byte patterns, which is not
> enough to consistently detect APKs.
> 

Do you have a link to the libfile discussion, and could you provide some more 
detail on the APK file format? I think in diffoscope we *are* happy to add more 
complicated detection logic.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Processed: Re: Bug#868486: diffoscope often fails to detect APKs

[Debian Bug Tracking System]

Processing control commands:

> tags -1 - pending
Bug #868486 [diffoscope] diffoscope often fails to detect APKs
Removed tag(s) pending.

-- 
868486: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868486
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#866120: diffoscope: please add an xml comparator

[Chris Lamb]

Hey Juliana,

> Yes! I would like to work on fixing that. Also, I'll take a look at the
> other failed tests and get back at you. (:

Any news on this? We'd love to get the tests all passing again :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: About compile randomness for clojire or antlr

[Chris Lamb]

Hi William,

> these code were compiled into different bytecode every time. the
> randomness are from some ordering problem for variable definitions
> or instruction sequences when i using javap to disassemble the class.

First, is the code in question a parser generator? If so, those often
result in non-deterministic output as they often iterate over hashes
etc. in their output.

However, if it's not we have seen this in entirely "static" code:

  
https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_java_bytecode_issue.html

… and, as the page mentions, we don't know why it happens. Can you spot
anything perculiar about those packages? (eg. do they all use Clojure;
could it be that...?)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds