Jump to content
Ketarin forum

Ketarin 1.7.0 b2


floele
 Share

Recommended Posts

  • Replies 83
  • Created
  • Last Reply

Top Posters In This Topic

Each app should also indicate on the front-end if there are pre/post commands associated with it. I'm not comfortable with the ability for a third party to upload an app profile with potentially significant security risks within the pre/post commands. Perhaps require an extra click/confirmation if there are pre/post commands included in the script so they release you from liability. Sure, we can assume that liability is released anyway (it might be good to include a disclaimer in the footer), but when it comes to something like this that can effectively run random code on a users computer, it might be better to flag it on the front end and make them jump through an extra hoop to get it just to be safe.

 

Do you have a testable version of Ketarin with upload/sync ability yet?

Link to comment
Share on other sites

BTW: All new applications are now sent into the database you see in the forum. Remember to add your "DB Guid" to your user profile so that your username is shown next to the application.

 

We still need to decide how to proceed with the old apps. Either we delete them all and start clean, or we remove all bad ones and start from there. Your decision.

 

What else do we need to make the whole system more useful?

Link to comment
Share on other sites

Delete them all and start fresh. Trying to just prune the bad ones would take far more time and most likely plenty will slip under the radar and stifle adoption from new users if they find frustration at some apps not working.

 

And besides those would contribute fresh/new would have most likely tweaked whatever they submit to be very clean running.

 

Happy to see development is ongoing.

Link to comment
Share on other sites

My vote is to purge and start all over.

 

Is the Author GUID tied to the Ketarin database or the machine? Is it treated as unique within the forum so nobody else can try to claim it once they learn what someone elses GUID is? I will sometimes run my ketarin updates on different devices, and have in the past given copies of the complete database away. I just want to make sure that sharing Ketarin databases isn't going to give someone else the capability to pose as me when submitting apps. Perhaps two-way authentication to minimize potential pollution or damage? That is, require a GUID generated from the database/client side to be copied manually to the server (as now) but also require a GUID from the forum user profile to be copied to the database?

Link to comment
Share on other sites

The GUID is part of the database. Unless you give your database to other persons (you should not, that's what export features exist for), no one will get to know your GUID.

 

I'm not sure how your "two way authentication" is meant.

Link to comment
Share on other sites

I'll have to stop sharing my databases, apparently. How long has the GUID been populated in the database? Maybe I should rebuild my database to create a new unique GUID?

 

 

The two-way authentication would ensure that someone could not hijack someone else's role simply by having a copy of their database. For example, if the computer for SampleUser is infected and the attacker harvests his GUID he would currently be able to publish new updates as SampleUser, to the website. He could effectively hijack legitimate app profiles or cause other forms of damage, including infecting third parties that update their app profiles but also impacting the user's reputation. While unlikely, unintentional GUID collisions could also occur. 128-bits of entropy is nice, but 256 would be even better. :)

 

Ideally, when I make a change to publish a new app profile, it should verify both my GUID as well as a unique server key that's generated exclusively on the server side within the forum. This way both sides have to have been acknowledged in some fashion. At any moment a user should be able to disavow and regenerate their server-side key in order to re-secure their connection should the hijack scenario above occur. The server key would be a way to immediately disavow those third-party attempts and identify unapproved attempts to change profiles. If you store both the "active" server key and the user GUID in the server-side database for each profile, it would also make it much easier to track down forged profiles.

 

Sure, it's possible that I'm overthinking the process, but I'm a security guy and I see the worst case scenario in everything I look at.

Link to comment
Share on other sites

Maybe I should rebuild my database to create a new unique GUID?

 

Yes, you should.

 

 

 

unintentional GUID collisions could also occur. 128-bits of entropy is nice, but 256 would be even better

 

It's not unlikely. It's pretty much impossible. Now consider how many Ketarin users there are and how likely it would be that two of those generate the same GUID by accident.

 

 

 

but I'm a security guy and I see the worst case scenario in everything I look at.

 

We are talking about a rather non-critical consequences though, so I consider it overkill for now.

Link to comment
Share on other sites

Looks good. Much easier to check them for potential issues now.

 

Can you have remove the PreviousLocation block and ensure that the ExecuteCommand is empty? Windows 7 USB Tool is still publishing an ExecuteCommand block and the potential for user information leakage exists in the PreviousLocation element.

 

It should also have something on the front-end that indicates what global variables might need to be assigned. This should be any variable that is referenced ("{something}") but is not included in the Variables group.

Link to comment
Share on other sites

Guest Paul T

Looks good.  I vote for deleting all and starting again - so much that doesn't work in there.

 

Being able to search for less than the minimum 4 characters would really help out.  e.g. AVG

Link to comment
Share on other sites

Can you have remove the PreviousLocation block and ensure that the ExecuteCommand is empty?

 

Changed the server side now so that this information is removed on upload.

 

The variables-stuff is hard to do at the moment.

Link to comment
Share on other sites

Is it just me or is something broken? Nearly all my packages are showing as needing an update - filehippo or not! Using the Ketarin 1.7.0-b2.zip at the top of this post ...

 

Same here. If I'm using FileHippo ID it gets updated all the time. Tested with 170b2 and 170b2-u5. 

Link to comment
Share on other sites

Another issue I see before we clear the current database is the naming convention. We need to settle on some way how apps should be named, otherwise it'll get messy soon.

 

We could for example use

 

Application Name 1.0.0 [beta|alpha] (English)
for 32 bit apps and

 

Application Name 1.0.0 [beta|alpha] 64-bit (English)
for 64 bits. What do you think?
Link to comment
Share on other sites

Can we just allow admins to rename apps after upload? Likewise the system should be set not to rename them on the client during an application profile update if the only changes the user has made are the name and destination information (and of course, leave those alone).

 

On my end, many of my apps are named specifically based on their purpose, not necessarily the application name. For example, the only good reason to download the RK Tools for XP today is for robocopy, thus "XP RK Tools (robocopy)". This wouldn't behave well for me if I had to use actual product names in a normalized convention.

 

For 32 & 64 bit releases, I usually append either "(x86)" or "(x64)" to the end of the app name, such as "SmartSniff (x64)", and only in those cases where bit-specific releases are available. If no bit-specific versions are available, it doesn't make sense to tag the name.

Link to comment
Share on other sites

 

Another issue I see before we clear the current database is the naming convention. We need to settle on some way how apps should be named, otherwise it'll get messy soon.

 

We could for example use

 

for 32 bit apps and

 

for 64 bits. What do you think?

 

 

Well I personally use x86/x64 naming scheme...by adding x64 for only 64-bit Installers/Apps/versions...

Link to comment
Share on other sites

I've always gone Application name (architecture|other specific information like dependencies or things that aren't immediately obvious)

 

e.x.

-CCleaner - Standard

-CCleaner (x64) - It is pointless to put in x32, because 90% of programs will probably be 32-bit only still. So cluttering up the DB with unimportant information seems a tad pointless and will just make WHAT we look for a bit more confusing. You could try to put in other columns as standard like Architecture|Dependencies|Install Method then we wouldn't need to clutter up the application name.

-Sickbeard (TorrentFork|GithubSource|Python) - Sickbeard has both source and binary that can be run from windows

 

But I only do that for installers that are have explicit requirements that would not be obvious just from the application name. I mean the base understanding is 'this is a file you download and install/unzip/uniextract to run' with no other real dependencies or anything else. Granted these are special cases, but the 'extra' naming conventions should only be to make things that would not be immediately obvious.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.