I chose to create a 512MB encrypted (heavy) pup_save for an install to USB stick. On reboot into the system the new 512MB encrypted pup_save gets detected on the stick OK, but the freemem applet only shows 69MB as being available. I Gig USB stick is formatted to VFAT and PMOUNT reports the correct amount of unused space.

If an attempt is made to download a file larger than 69MB to the root folder with Seamonkey , the freemem applet shows its usual low memory warning whereupon Seamonkey then crashes.

On the next reboot the partially downloaded file is still there, but freemem then shows available free memory as back to 69MB.

Something seems to be going wrong when the 2 layers are merged in the shutdown script. I don't understand this area of Puppy very well. Some explanation would be appreciated here._________________Life is too short to spend it in front of a computer

You you be on PUPMODE 13, and it is calculating free space in RAM (pup_rw) and free space in your pup_sve file (pup_ro1) and using the smaller of the two.
In other words, you may have plenty of RAM space but your pup_save is full so there is no point putting more than that into RAM as there is insufficient space to save it..

How would reads/writes to the swap-file affect the operating life of the stick?. Would it speed things up to any significant extent anyway (i.e is it worth having a swap-file in PUPMODE13 at all especially when encryption is involved?)_________________Life is too short to spend it in front of a computer

Posted: Mon 21 May 2007, 10:36 Post subject:
Agree, if used, encrypted swap is a must for good security.Subject description: Not if there were a way to use the encrypted pup_save file from CD

All of the machines I boot puppy from have enough RAM that a swap file is not required; however, it would be nice if I could store the encrypted pup_save file on the puppy boot CD and use it in a read only mode, IE.. no RW media required to store the pup_save file. As a work around, I currently store the pup_save file on the CD with a diffent name then copy/rename it to R/W media, reboot to access contents and delete when finished. Also, the encrypted pup_save file contents is available as clear text while in use. I like the idea of having the option of running totally from optical boot media then simply powering the computer off at the end of the sessions, IE.. great mode for open wireless.

Seems like a lot of work to avoid having to do a shutdown. But maybe I miss the point.

Quote:

Also, the encrypted pup_save file contents is available as clear text while in use.

I believe the pup_save file proper remains encrypted, but of course stuff read from there into memory is cleartext while in memory (and in swap, if one is so rash as to use it). If that's so, that's about as good as it gets anywhere in the world of encryption. Correct me if I'm wrong...

Quote:

I haven't looked at the encryption stuff in this Puppy but it should ideally warn the user to disable swap if using encryption, or, better, it should encrypt swap.

I have nagged about that, in vain I think (I haven't done anything with 2.16 so don't know for sure). Actually I lobbied to get the boot to happen with swap off by default if encryption is used.

I had decided to delete my swap partition so I wouldn't need to run a swapoff command in my rc.local to disable the swap, but when I did that, puppy created a pupswap.swp file for me anyway, without even asking me if I wanted it! So now I have "swapoff /initrd/mnt/dev_save/pupswap.swp" in my rc.local...

John Doe did some work with dmcrypt which would have allowed encrypted swap, but at the time Puppy's use of Busybox commands made it impossible. The offending command has now been made a full one, so a hard-core encryption fan might take another shot at it. Search the forum for his work on this.

Bottom line, if you use encryption now, you need to disable swap manually and have enough memory not to need it. A simple warning to this effect sure would be worthwhile, if nothing else.

Quote:

But of course serious people use loop-aes with multiple gpg encrypted keys and not that cryptoloop ....(just kidding!!)

Well, we are only half serious around here.

As someone who has done his fair share of sniping at cryptoloop, I can sympathize. But hey, it's a heck of a lot better than what we had before! While I wouldn't hide stolen cruise missile plans in my pupsave, heh heh, I figure good (or bad) old cryptoloop delivers 95% or 98% of the utility of loop-aes and dmcrypt. And that's nothing to sneer at...

It wouldn't hurt for another hard-core encryption geek to join the Puppy development team. Maybe some day we could have more up-to-date encryption alternatives and features. As it is right now, though, I'm happy.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum