It's kinda moot - anybody with access to your system and able to pull it from the file - could just as easily tweak the client and patch the password entry field to pluck the password. Depending on how PA is gonna handle logins long term - esp with the multi-server (which might not be under PA's control) and licensing - something like Google 2FA might be better. It's pretty simple to implement.
I remember there was some discussion about this, most notably with regards to Firefox and Chrome. The issue was that when they save passwords, these programs save them in a plaintext file, unencrypted. However, the problem with storing any password locally in an open-source program is that even if it is encrypted, it's simple enough to get the key and decrypt the file using the method found in the code. With a closed-source program, like PA, it's a bit harder, since the method and key would not be immediately known. However, it is not difficult to figure this information out through a bit of analysis, and once again, the security is compromised. The only proper way to encrypt the information is for the user to provide their own key to encrypt with, which only serves to make the system redundant. The better solution (on Linux) is to rely on the operating system's permissions and disk-encryption methods to prevent external access to the file. On Windows Vista+, the methods MS implemented should work with similar effectiveness, but don't quote me on that. (And for Macs, I don't know.) Of course, the method is flawed in that most users nowadays don't bother to set up user accounts for individual users on shared computers in the home, and they rarely lock their computers when away from them. So really, the security of a system depends on the user. (And most notably for Linux users, there's the liberal use of commands like sudo that certainly doesn't help matters.) In any case, whether the password is stored in a plaintext or an application-encrypted file, it's going to be equally insecure if the system permissions aren't enforced. So really, encrypting the password file is only a "feel good" solution.
Heard a report on the latest build doing something bad to the UI or menuing in game. If anyone is experiencing this, details please (Linux specifically)
Finally new Steam beta has 64-bit game support. I just tried PA with that and the overlay is working now
If you move your mouse over things the rendering glitches. Apparently uploading OGV files is disallowed, so here's a link instead: http://www.compholio.com/misc/menu-problem.ogv (The menu rendering weird is _not_ an artifact of the recording.) Edit: My first game on this new build also resulted in a featureless planet (moon looks fine), is that to be expected?
Hmm.. wonder if that's us, or Coherent. Looks like a Coherent bug (we just integrated the new version a day or so ago).. might be related.
If the old version and the new version are compatible you could send me the old one and I can swap it out and give it a try.
49789 certainly seems alot more functional with OSX 10.8.4 but still getting hard locks after 5-10mins of play.
yup there are graphic glitches and times when the cursor vanishes (have to go between maximise & windows and moving mouse in out of game area to have it return). on a plus note left-click select works so could actuall build, attack, assist-build etc... manage to get through alot of a game (before hand I would get a few bld up, a few units built and something would get stuck and then no point doing anything). Still a few instances when a unit leaving a fab will get stuck USUALLY if a unit is being built and a bld finishes where the bot would come out then that unit is stuck. That said I did experience my 1st lockup and gfx corruption after 20min of "playing" forgot to take logs and the dmp. will try to reproduce tonight
It's not due to the new Coherent build - that appeared in 49658 (according to the buildID) - but it might be being used in a new & exciting way. The appearance of mouse pointers have changed in this build from the system default pointer. Mouse-over anything from game launch causes severe flickering in the game and extends to some of the other out of game windows (MPlayer - a movie renderer flickers when PA is flickering. So the bug is effecting direct draw windows system wide. Moving the mouse out of the PA window causes the flickering to stop in-game but often (not always) continues in the other windows. Bringing the mouse back into the window (but not over any other screen element) and the mouse flickers but the game doesn't - flickering starts again in other windows on the machine that were flickering before. On game start the license panel stays open even if accept is clicked unless you move the mouse pointer out of the PA game window.
Running Ubuntu 13.04 64bit with Cinnamon desktop, i see no issue and the mouse pointer is finally correct Played a game for a couple minutes and no Linux specific issues so it's the best build by far for me Edit > Testing using Ubuntu's default desktop Unity and no issues either. What desktop are you running and what graphics card do you have since it doesn't happen to me it sounds like an issue your end.
AMD 13.4 (latest stable release) on a 7950 with 3GB onboard. Linux Mint 15/Ubuntu Ringtail running Kernel 3.9.0-030900-generic X.Org X Server 1.13.3 running MDM 1.2.5 with Cinnamon 1.8.8 Earlier builds didn't have this issue on the same hardware. As other windows are flickering when the game is flickering - its feels like there some kind of gpu corruption going on. There's been recent game changes to sync iirc - which might be related. I've noticed that sometimes it feels as if the game isn't releasing it's hold on the gpu properly causing other apps that use the GPU to fail until MDM or the machine itself restarted. I've seen it before with my own code when writing things that use the GPU - if there's a fault - sometimes it doesn't properly release GPU resources causing rerunning the app to just bork until a reset.
Thought so, I bet it's and AMD issue I would be interested to see if anyone on Nvidia has the issue as for me it's functioning perfectly.
I did a bit of testing on my rig. So what I found: I get small corruptions in menu only when KDE compositing is enabled. So it is probably that other people are experiencing similar issues (and the whole situation with compositing, vsync, tearing and so on really sucks on Linux). As I see it there are two paths: 1. Disable compositing if you can (on Ubuntu, iirc, you can't disable compositing). 2. Wait for Uber to add fullscreen mode and there is a setting in almost all window managers - Disable compositing for fullscreen applications.
iirc you can disable compositing with the following in your xorg conf But most modern window managers require it enabled I think. I'll check my vsync settings - that has an impact on it also I think. [Edit: Might be relevant] I run 2 monitors using the multi-display desktop - so essentially 2 desktops - rather than using the stretched desktop on 2 monitors. I can try a stretched desktop if it's worth it - but you know AMD.. sneeze and you need to restart for the changes to be applied
