Metalinks / Code Commit Log

Commit	Date
[r575] by antbryan Publisher & Metalink Processor (to be consistent)	2010-02-06 01:46:27	Tree
[r574] by antbryan Lisa: Normally, a content creator is in the best position to know how strong the protective signing ought to be on their content. Thus, a content creator can choose weak or strong cryptography, and a content consumer would normally accept that. There MAY be applications where the content consumer chooses to reject weak cryptography, but that is not envisioned as the common use case.	2010-02-06 01:41:47	Tree
[r573] by antbryan Although signing and verifying signatures are both OPTIONAL, an implementation that supports either feature SHOULD implement RSA with a minimum key size of 2048 with SHA-256. Metalink Processors that support verifying signatures MUST reject Metalink Documents with invalid signatures. If weak cryptography is used in a Metalink Document, such as legacy or marginal algorithms or key sizes (i.e., MD5 or 512 bit RSA)...	2010-02-05 23:02:55	Tree
[r572] by antbryan Remove atom/html sentence.	2010-02-04 08:37:58	Tree
[r571] by nabber00 added notes on what to do next	2010-02-02 07:23:20	Tree
[r570] by antbryan Alexey: Metalink Processors that encounter foreign markup in a location that is legal according to this specification MUST ignore such foreign markup, in particular they MUST NOT stop processing or signal an error.	2010-01-31 01:50:30	Tree
[r569] by antbryan metalink-27 final	2010-01-28 18:35:50	Tree
[r568] by nabber00 added license for GTK	2010-01-26 23:42:23	Tree
[r567] by nabber00 updated build process to work with gtk files in current directory	2010-01-26 17:43:47	Tree
[r566] by nabber00 added gtk+ files	2010-01-26 11:22:28	Tree

[r575] by antbryan

Publisher & Metalink Processor (to be consistent)

2010-02-06 01:46:27

[r574] by antbryan

Lisa:

Normally, a content creator is in the best position to know how strong the protective signing ought to be on their content. Thus, a content creator can choose weak or strong cryptography, and a content consumer would normally accept that. There MAY be applications where the content consumer chooses to reject weak cryptography, but that is not envisioned as the common use case.

2010-02-06 01:41:47

Tree

[r573] by antbryan

Although signing and verifying signatures are both OPTIONAL, an implementation that supports either feature SHOULD implement RSA with a minimum key size of 2048 with SHA-256.

Metalink Processors that support verifying signatures MUST reject Metalink Documents with invalid signatures.

If weak cryptography is used in a Metalink Document, such as legacy or marginal algorithms or key sizes (i.e., MD5 or 512 bit RSA)...

2010-02-05 23:02:55

Tree

[r572] by antbryan

Remove atom/html sentence.

2010-02-04 08:37:58

Tree

[r571] by nabber00

added notes on what to do next

2010-02-02 07:23:20

Tree

[r570] by antbryan

Alexey:

Metalink Processors that encounter foreign markup in a location that
is legal according to this specification MUST ignore such foreign markup,
in particular they MUST NOT stop processing or signal an error.

2010-01-31 01:50:30

Tree

[r569] by antbryan

metalink-27 final

2010-01-28 18:35:50

Tree

[r568] by nabber00

added license for GTK

2010-01-26 23:42:23

Tree

[r567] by nabber00

updated build process to work with gtk files in current directory

2010-01-26 17:43:47

Tree

[r566] by nabber00

added gtk+ files

2010-01-26 11:22:28

Tree

Metalinks Code

Code Commit Log