Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Ganymede Must Do's (#13, #15)

How fine-grained is the size information, and how much does signing
change the jar size? Also, does anything validate that the size listed
== the size downloaded, or is this just for estimating disk footprint
at install time?

If this is just to provide information, then I don't see the problem
if the values are only pre-signing estimates.

If this is to do actual validation to avoid installing a malicious
jar, then the value needs to be an accurate post-signing value. As
Andrew points out, this information would then need to be stored
outside the jar (or added during signing somehow?).

But if we store it outside the jars as information about the site's
features, these need to be aggregate numbers of feature + contained
feature(s) + contained plugin(s), or else add a lot of extra
information into the site.xml to effectively list all the
features/plugins and their individual sizes.

Once again, what's the purpose of this information? Providing
footprint estimate? Aggregate OK. Avoiding bad jars? Individual data
for each feature/plugin jar.

Then again... if the point here is to avoid bad jars... isn't that
what signing is for? Does the size matter at that point?

So... seems to me that ther are two reasonable solutions here:

a) generate an estimated pre-signing size and put that in feature.xml
b) generate a feature aggregate size when generating site.xml

$0.02,

Nick

On Nov 2, 2007 1:39 PM, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:
>
> Getting download sizes into features will actually turn out to be rather
> difficult.
> Kim pointed out that the problem is that we are signing our jars.  This will
> change their size, and you can't go and modify the feature.xml after the
> feature has been signed.
>
> This means that plugins and features would need to be split into 2 groups,
> the plugins signed first, then the features modified with download sizes.
> And we won't be able to compute sizes for feature jars since they will
> change after signing.
>
> I don't know what the format of the site.xml is, but it would be much easier
> to store download sizes there rather than in the feature.xml


Back to the top